Analyse du graphe d'appareils : relier les points entre les sessions
Comment les bases de données de graphes révèlent des connexions cachées entre appareils, permettant la détection de multi-comptes et l'identification de réseaux de fraude à grande échelle.
Lorsqu'un seul fraudeur exploite des dizaines de comptes, chaque compte pris isolément paraît légitime. Chacun a une adresse e-mail unique, une adresse IP plausible, des habitudes de navigation réalistes. La détection traditionnelle à base de règles vérifie chaque compte indépendamment et ne trouve rien de suspect. Les connexions entre comptes — les appareils partagés, les sessions qui se chevauchent, les empreintes réseau communes — sont invisibles pour les systèmes qui traitent les comptes un par un.
Pourquoi des graphes
L'analyse du graphe d'appareils change le modèle. Au lieu d'évaluer les comptes indépendamment, nous construisons un graphe où les nœuds sont des appareils, des comptes, des adresses IP et des sessions, et où les arêtes représentent des connexions observées : « cet appareil a servi à créer ce compte », « cette IP a été vue avec cet appareil », « ces deux comptes ont partagé un cookie de session ». Le graphe révèle une structure que les tables plates ne peuvent pas montrer.
Un réseau de fraude qui utilise 50 comptes répartis sur 5 appareils et 3 adresses IP forme un cluster caractéristique dans le graphe. La densité du cluster — de nombreuses connexions au sein d'un petit groupe de nœuds — est un signal fort. Les utilisateurs légitimes partagent rarement leurs appareils avec des inconnus, et leurs connexions compte-appareil forment des structures dispersées et arborescentes plutôt que des clusters denses.
Architecture de la base de données de graphes
Nous utilisons un modèle de graphe de propriétés avec quatre types de nœuds : Device (identifié par l'identifiant visiteur), Account (votre identifiant utilisateur), Network (adresse IP + ASN) et Session (événement d'identification individuel). Les arêtes portent des métadonnées : horodatage, score de confiance et type d'événement.
Le graphe est stocké dans un index d'adjacence conçu sur mesure et optimisé pour les parcours à 2 sauts. Lorsqu'un nouvel événement d'identification arrive, nous insérons l'événement comme un nœud Session, le connectons aux nœuds Device et Network, et vérifions si un Account lié possède des connexions vers d'autres appareils. Cette opération d'insertion et de requête se termine en moins de 5ms pour des graphes allant jusqu'à 10 millions de nœuds.
En réalité, nous avons d'abord essayé Neo4j. Il fonctionnait à merveille en développement avec 100K nœuds. Puis nous avons chargé les données de production — 500M de nœuds — et les requêtes Cypher qui prenaient 2ms se sont mises à prendre 800ms. David a passé une semaine à évaluer des alternatives avant que nous construisions notre propre index d'adjacence adossé à du RocksDB partitionné. Parfois, la solution ennuyeuse et sur mesure surpasse l'élégante solution toute faite.
Algorithmes de clustering
Nous appliquons deux algorithmes de clustering au graphe d'appareils :
Composantes connexes
L'approche la plus simple : trouver tous les nœuds atteignables depuis un appareil donné. Si Device A est connecté à Account 1 et Account 2, et que Device B est aussi connecté à Account 2, alors Device A et Device B appartiennent à la même composante connexe. Cela identifie tous les comptes qui partagent une connexion transitive quelconque via un appareil.
Les composantes connexes sont rapides à calculer, mais peuvent produire de très grands clusters lorsque des appareils partagés légitimes (ordinateurs familiaux, terminaux de bibliothèque) créent des ponts entre des comptes sans lien. Nous corrigeons cela par une pondération des arêtes : les connexions passant par des environnements partagés connus reçoivent un poids plus faible.
Détection de communautés
Pour une analyse plus nuancée, nous exécutons la détection de communautés de Louvain sur le graphe pondéré. Cet algorithme partitionne le graphe en communautés où les connexions intra-communauté sont denses et les connexions inter-communauté sont dispersées. Les réseaux de fraude forment des communautés compactes même lorsqu'ils sont reliés au graphe plus large par une infrastructure partagée.
L'algorithme de Louvain s'exécute en temps O(n log n), ce qui le rend praticable pour des graphes de plusieurs millions de nœuds. Nous l'exécutons de façon incrémentale : lorsque de nouvelles arêtes sont ajoutées, nous mettons à jour localement les affectations de communauté au lieu de recalculer toute la partition.
Cas concret : détection de réseau de fraude
Une plateforme de jeu a intégré notre API de graphe d'appareils pour détecter des réseaux de fraude organisés. Dès la première semaine, le graphe a révélé un cluster de 127 comptes reliés par 8 appareils et 4 adresses IP. Les comptes avaient été créés sur une période de 3 mois, chacun avec une adresse e-mail unique et un profil réaliste. La détection à base de règles n'en avait signalé aucun.
La structure du graphe a trahi le réseau : 127 comptes partageant 8 appareils produit une moyenne de 15.8 comptes par appareil. Les utilisateurs légitimes affichent en moyenne 1.2 compte par appareil sur cette plateforme. La densité du cluster était 47x au-dessus de la référence — un signal de fraude sans ambiguïté.
Performance à grande échelle
Notre graphe d'appareils de production gère 2,3 milliards de nœuds et 8,1 milliards d'arêtes. La latence d'insertion est de 2.4ms au p99. Le parcours à deux sauts (trouver tous les comptes reliés à un appareil par un chemin de longueur 2 quelconque) se termine en 4.1ms au p99. Les mises à jour de la détection de communautés traitent 50 000 nouvelles arêtes par seconde.
Le graphe est partitionné par hachage de l'identifiant d'appareil sur 12 nœuds, chaque shard contenant environ 190 millions de nœuds. Un facteur de réplication de 3 garantit la disponibilité. Nous prenons un instantané du graphe toutes les heures pour la reprise après sinistre et exécutons quotidiennement un recalcul complet de la détection de communautés comme contrôle de cohérence face aux mises à jour incrémentales.
Intégration
Le graphe d'appareils est accessible via deux interfaces : une API de requête en temps réel pour des recherches individuelles (cet appareil est-il relié à d'autres comptes ?) et une API d'export par lots pour l'analytique (donnez-moi tous les clusters de plus de N comptes). L'API en temps réel est conçue pour des décisions de fraude en ligne : interrogez-la pendant la création de compte pour vérifier si l'appareil a déjà vu d'autres comptes. L'API par lots alimente les flux d'investigation de votre équipe data.