Construire des modèles de détection de fraude sur les données de sinistres

# Construire des modèles de détection de fraude sur les données de sinistres

Un dossier de dommages corporels arrive sur le bureau d'un gestionnaire : une collision par l'arrière, trois occupants, tous déclarant des lésions cervicales des tissus mous, tous soignés dans la même clinique, tous représentés par le même avocat dans les 48 heures suivant l'accident. Pris séparément, rien d'illégal. Ensemble, c'est la signature manuelle d'un réseau de fraude organisée.

Votre travail, en tant que responsable data, est d'apprendre à un modèle à voir ce pattern, sans signaler les milliers de dossiers de whiplash légitimes qui ressemblent superficiellement au même profil.

Pourquoi la détection de fraude est un problème de données, pas de règles

Les assureurs utilisent des règles depuis des décennies. Une règle dit : « signaler tout sinistre supérieur à 10 000 $ dont le traitement commence plus de 30 jours après l'accident ». Les règles sont transparentes et faciles à auditer, mais les fraudeurs les apprennent et restent juste sous le seuil.

La fraude douce (exagérer un sinistre réel) et la fraude dure (un sinistre entièrement mis en scène ou fabriqué) évoluent toutes les deux. La fraude intéressante et coûteuse est organisée : des réseaux de praticiens, d'avocats et de « patients » qui recyclent le même playbook sur de nombreux dossiers.

C'est un problème de patterns. Et les patterns sur des milliers de dossiers, c'est précisément ce que les modèles de données savent traiter.

La Coalition Against Insurance Fraud publie une documentation solide et gratuite sur le fonctionnement de ces montages. Parcourez leurs ressources sur la fraude avant de concevoir vos features ; comprendre le délit vous rend meilleur pour en construire les signaux.

Commencez par l'unité d'analyse

Les débutants modélisent « le sinistre ». Les réseaux de fraude vivent *entre* les sinistres. Il vous faut donc trois niveaux :

• Niveau sinistre : un événement de perte.
• Niveau entité : une personne, une clinique, un véhicule ou un avocat qui apparaît dans de nombreux dossiers.
• Niveau réseau : la manière dont ces entités se connectent.

Un seul dossier suspect vous apprend peu de choses. Le même chiropracteur présent sur 200 collisions arrière à faible vitesse avec des plans de traitement quasi identiques vous en apprend beaucoup.

Feature engineering : transformertransformerUn Transformer est une architecture de réseau de neurones qui utilise le self-attention pour traiter des séquences en parallèle. Elle est au cœur de la plupart des modèles de langage et d'IA générative actuels.Voir la définition complète → la scène en signaux

Convertissons notre dossier d'ouverture en features lisibles par un modèle.

Features au niveau du sinistre

• Nombre de jours entre l'accident et le premier traitement (très court ou étrangement tardif, les deux comptent).
• Intensité du traitement : nombre de consultations relativement à la gravité de la blessure.
• Ratio entre lésions des tissus mous (difficiles à réfuter) et lésions objectivement vérifiables.
• L'accident a-t-il été déclaré à la police ? Y avait-il des témoins indépendants ?
• Heure de la journée et lieu (certains accidents mis en scène se concentrent sur des points précis).

Features au niveau de l'entité

C'est là que la fraude organisée se révèle.

• Sur combien de dossiers cette clinique, cet avocat ou ce garage apparaît-il cette année ?
• Quelle part des dossiers d'un praticien concerne le même type de blessure ?
• Les mêmes trois occupants apparaissent-ils ensemble sur des accidents antérieurs ?

Features de vélocité et de coïncidence

• Nombre d'occupants ayant tous déposé une déclaration de blessure (les accidents mis en scène maximisent le nombre de demandeurs par accident).
• Avocat mandaté en moins de X heures (représentation juridique rapide, avant que la douleur ne s'installe de manière réaliste).
• Plusieurs demandeurs partageant une adresse ou un numéro de téléphone.

Aucun de ces éléments n'est une preuve. Chacun est un signal faible. Le rôle du modèle est de combiner de nombreux signaux faibles en un score de risque calibré.

C'est dans le graphe que se cachent les réseaux

Les modèles tabulaires classiques manquent le tissu conjonctif. Un réseau de fraude est naturellement un graphe : les nœuds sont des personnes, des cliniques, des véhicules, des numéros de téléphone et des comptes bancaires ; les arêtes sont des dossiers partagés.

Construisez le graphe, puis calculez-en les features :

• Degré : combien de dossiers un nœud touche.
• Composantes connexes : des clusters fortement liés de demandeurs, de praticiens et d'avocats qui reviennent ensemble.
• Liens par attribut partagé : deux demandeurs « sans rapport » utilisant le même numéro de téléphone forment une arête forte.

import networkx as nx

# Nœuds : demandeurs, praticiens, avocats, téléphones, VIN
# Arêtes : apparaît-sur-le-même-dossier ou partage-un-attribut
G = nx.Graph()
G.add_edge("claimant_A", "clinic_9")
G.add_edge("claimant_B", "clinic_9")
G.add_edge("claimant_A", "phone_555")
G.add_edge("claimant_B", "phone_555")  # attribut partagé suspect

# Repérer les clusters serrés qui reviennent d'un dossier à l'autre
components = list(nx.connected_components(G))
suspicious = [c for c in components if len(c) > 15]

Un cluster de quinze « inconnus » passant tous par une même clinique et un même numéro de téléphone, c'est le réseau. Ce fait structurel est une feature que vous injectez dans le modèle en aval.

Choisir le modèle : supervisé, non supervisé, ou les deux

Vous avez rarement des labels de fraude propres. La fraude confirmée est une tranche minuscule et biaisée : uniquement les cas que quelqu'un a déjà attrapés. D'où une approche par couches.

Modèles supervisés

Entraînez sur des dossiers de fraude confirmée (enquêtée et prouvée) et des dossiers légitimes confirmés. Les arbres boostés par gradient (XGBoost, LightGBM) gèrent bien les features mixtes et fournissent des importances de variables que les gestionnaires peuvent inspecter. Bien adapté aux patterns *connus*.

La faiblesse : ils n'apprennent que la fraude qui ressemble à la fraude passée.

Détection d'anomalies non supervisée

Pour les montages nouveaux, utilisez la détection d'anomalies : isolation forests, autoencodeurs ou clustering. Ces méthodes signalent les dossiers qui s'écartent de la normale sans avoir besoin de labels. L'objectif n'est pas de déclarer « fraude » ; c'est de dire « statistiquement inhabituel, regardez de plus près ».

La stack pratique

La plupart des assureurs matures font tourner les deux : un score supervisé pour les typologies connues, un score d'anomalie pour l'inconnu, et des features de graphe qui alimentent les deux. Un dossier élevé sur les trois part directement vers la Special Investigations Unit (SIU), l'équipe interne qui enquête sur les fraudes suspectées.

Le problème des faux positifs, c'est tout l'enjeu

Voici le piège. Supposons que la fraude représente environ 10 % des dossiers (une estimation souvent citée ; les taux réels varient selon la branche et sont difficiles à mesurer précisément, puisque la fraude non détectée est par définition non comptée).

Si votre modèle signale 30 % des dossiers « par précaution », vous avez enseveli votre SIU. Les gestionnaires perdent confiance, ignorent les alertes, et tout le système meurt. C'est l'alert fatigue, et elle tue plus de programmes anti-fraude que les mauvais calculs.

Deux disciplines corrigent cela :

1. Optimisez la précision à faible volume. Vous n'avez pas besoin d'attraper toutes les fraudes. Vous avez besoin que les 2 % de dossiers signalés en tête méritent réellement le temps d'un enquêteur. Mesurez la precision at k : sur les 100 premiers dossiers signalés, combien sont réels ? C'est ce chiffre qui intéresse votre SIU.

2. Rendez les scores explicables. Un gestionnaire n'agira pas sur « le modèle a dit 0,87 ». Donnez des raisons : « même clinique sur 180 dossiers, trois occupants co-apparus sur un sinistre antérieur, avocat mandaté en 6 heures ». Des outils comme les valeurs SHAP transforment un score en une courte liste de facteurs. L'explicabilité est aussi de plus en plus une attente réglementaire, puisque signaler un assuré comme suspect a des conséquences réelles.

Gouvernance : terrain réglementé

Les modèles anti-fraude touchent à des décisions protégées. Quelques garde-fous :

• N'utilisez pas de variables interdites ou de proxys. Des features corrélées à l'origine ethnique, la religion ou la nationalité peuvent crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éererLe rapport entre les interactions (likes, commentaires, partages) et le reach d'un contenu, utilisé pour mesurer la réaction de l'audience au regard du nombre de personnes touchées.Voir la définition complète → une discrimination illégale, même involontairement. Testez l'impact disparate.
• Gardez un humain dans la boucle. Le modèle oriente les dossiers vers une revue ; il ne doit pas refuser automatiquement. Le refus est une décision humaine et documentée.
• Documentez tout. Les régulateurs et les tribunaux peuvent demander pourquoi un dossier a fait l'objet d'une enquête. « Le modèle l'a signalé » ne suffit pas.

La NAIC (National Association of Insurance Commissioners) publie des orientations continues sur l'usage de l'IA et des données en assurance ; il vaut la peine de les suivre à mesure que les attentes se durcissent jusqu'en 2026.

Boucler la boucle : le feedback fait la différence

Un modèle anti-fraude ne s'entraîne pas « une fois pour toutes ». Chaque enquête de la SIU produit un nouveau label : fraude confirmée, ou dossier blanchi. Réinjectez ces résultats.

Deux mises en garde :

• Biais de confirmation. Si vous n'enquêtez que sur ce que le modèle signale, vous n'apprenez que sur les dossiers que le modèle soupçonnait déjà. Enquêtez périodiquement sur un petit échantillon aléatoire de dossiers à *score faible* pour vérifier la fraude que le modèle rate. Sinon, le modèle devient aveugle avec assurance.
• Concept drift. Les réseaux s'adaptent. Quand votre signal principal (une clinique, par exemple) est démantelé, le pattern se déplace. Surveillez si vos importances de features évoluent dans le temps, et réentraînez sur une fenêtre glissante.

Retour à notre dossier

Notre dossier d'ouverture : trois occupants, une clinique, un avocat rapide, tous en tissus mous. Passons-le dans la stack :

• Features de sinistre : nombre d'occupants élevé, avocat rapide, blessures peu vérifiables. Niveau élevé.
• Features d'entité : cette clinique apparaît sur une part inhabituelle de collisions arrière à faible vitesse. Niveau élevé.
• Graphe : deux des trois occupants ont co-apparu sur un sinistre antérieur. Arête forte.

Score combiné : élevé, avec trois facteurs explicables. Le dossier part vers la SIU avec une justification claire, et les dix dossiers de whiplash légitimes traités le même après-midi (occupant unique, cadence de traitement normale, aucune entité partagée) passent sans encombre.

C'est l'objectif : attraper le réseau, épargner l'assuré honnête, respecter le temps du gestionnaire.

Points clés

• Modélisez le réseau, pas seulement le sinistre. La fraude organisée vit dans les connexions entre cliniques, avocats et demandeurs récurrents ; les features de graphe l'exposent.
• Superposez modèles supervisés et non supervisés. Les scores supervisés attrapent les typologies connues ; la détection d'anomalies attrape les nouvelles.
• La précision à faible volume vaut mieux que le recall brut. Protégez votre SIU de l'alert fatigue en ne signalant que les dossiers à plus forte valeur, avec des raisons explicables.
• Bouclez la boucle de feedback et auditez les angles morts. Échantillonnez les dossiers à score faible et surveillez le drift pour que le modèle continue d'apprendre à mesure que les réseaux s'adaptent.
• Traitez cela comme une décision réglementée. Testez l'impact disparate, laissez les humains décider des refus, et documentez pourquoi chaque dossier a été signalé.