FR 3057378 A1 20180413 FR 1659717 A 20161007 1 Système de détection de fraude dans un flux de données DOMAINE TECHNIQUE DE L'INVENTION La présente invention se rapporte au domaine de la sécurité des transferts de données sensibles et en particulier la sécurisation des échanges bancaires. Plus spécifiquement la présente invention concerne un système pour la détection de fraude dans un flux de données. ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION La sécurisation des données sensibles est un challenge majeur pour bon nombre de secteurs et en particulier dans le domaine bancaire où la sécurité des paiements/transactions est sans cesse éprouvée. Si l'évolution technologique des infrastructures informatiques fournit des moyens de lutte contre les fraudes ou piratages de données sensibles, elle permet également aux pirates informatiques de développer de nouvelles méthodes pour la récupération illégale ou frauduleuse de données. Plusieurs méthodes associant des techniques et modèles mathématiques complexes existent pour la détection de fraude dans un flux de données. Cependant, la portabilité ou l'application de ces modèles à des systèmes de données qui évoluent sans cesse et en temps réel est limitée, offrant par là un moyen aux pirates de récupérer des informations sensibles. DESCRIPTION GENERALE DE L'INVENTION La présente invention a pour but de pallier certains inconvénients de l'art antérieur en proposant un système pour détecter des fraudes lors d'un échange de données au cours d'une transaction bancaire, en particulier. 3057378 2 Cet objectif est atteint par un système informatique de détection de fraude dans un flux de données comportant au moins un lac de données permettant de stocker de gros volumes de données à structures variables, sous forme d'une base de données distribuée, pour des utilisations et 5 analyses diverses, une plateforme qui contient au moins un environnement de production comportant au moins une architecture matérielle et logicielle auto-adaptative comprenant une pluralité de modèles de contrôle de fraude mémorisés, un moteur de test et de mise à jour de modèles de contrôle de fraude, au moins une mémoire pour le stockage de données, au moins un 10 processeur, une couche de traitement en « temps réel » du flux de données et une couche de service, lesdites couches étant reliées par un moyen de communication, chacune des couches comprenant au moins du matériel et du logiciel implémentant un micro-service exécuté sur le processeur de l'architecture matérielle informatique pour permettre respectivement de 15 vérifier et/ou contrôler en temps réel le flux de données et de gérer dans la couche de service les données traitées, issues du traitement « temps réel », ladite architecture auto-adaptative étant caractérisée en ce qu'elle comprend également un ensemble d'apprentissage en ligne relié à la couche de traitement en « temps réel » pour réentraîner et mettre à jour en temps réel 20 des modèles de contrôle de fraude mémorisés dans la couche de traitement en « temps réel ». Selon une autre particularité, une sortie de la couche « temps réel » est connectée à l'entrée de l'ensemble d'apprentissage en ligne et la sortie 25 de l'ensemble d'apprentissage est reliée à une entrée de la couche de traitement en « temps réel » pour former une structure d'apprentissage en boucle. Selon une autre particularité, l'ensemble d'apprentissage en ligne 30 comprend des micro-services, chacun en charge de réentraîner des modèles de contrôle de fraude déployés dans la couche de traitement en « temps réel », et un système de redéploiement pour redéployer automatiquement les 3057378 3 modèles de contrôle de fraude réentraînés et mis à jour dans les micro-services de la couche de traitement en « temps réel » en charge de leur utilisation. 5 Selon une autre particularité, la couche de traitement en « temps réel » comprend un serveur de configuration pour mettre à jour en continu les paramètres des modèles de contrôle de fraude gérés par les micro-services de ladite couche de traitement en « temps réel ». 10 Selon une autre particularité, le système de redéploiement de l'ensemble d'apprentissage en ligne comprend un service central apte à recevoir une notification en provenance d'un micro-service dudit ensemble d'apprentissage lorsqu'un modèle a été réentraîné, ledit service central notifiant à son tour les micro-services de la couche de traitement en « temps 15 réel » qui sont concernés par la mise à jour des paramètres, via une API REST qui rechargera les paramètres dans le serveur de configuration de la couche de traitement en « temps réel », ledit serveur distribuant alors les paramètres aux micro-services concernés. 20 Selon une autre particularité, la structuration de l'architecture auto- adaptative en micro-services, communiquant entre eux par passage de messages, permet de découper la chaîne de traitement des flux de données, en un nombre N donné de micro-services, ledit nombre N correspondant au nombre de types de traitement à effectuer pour répondre à une requête 25 donnée, et de multiplier le nombre d'instances d'un type de service donné pour permettre un passage à l'échelle et assurer la continuité de service dans le cas où une instance est interrompue pour effectuer une configuration donnée. 30 Selon une autre particularité, le système de détection de fraude comprend également un environnement de développement de nouveaux 3057378 4 modèles de contrôle et/ou vérification de fraude du flux de données dans l'environnement de production. Selon une autre particularité, que l'environnement de développement 5 comporte une architecture matérielle informatique et logicielle de déploiement composée d'au moins un moteur de modélisation pour développer et tester les modèles de contrôle, ledit moteur de modélisation étant relié à un moteur de calcul distribué « map/reduce » configuré pour charger des données de production dans l'environnement de développement 10 et permettre l'évaluation en « temps réel » de nouveaux modèles de contrôle et, un déployeur de flux de données en charge du déploiement des modèles dans l'environnement de production. Selon une autre particularité, le déployeur de flux de données utilise 15 un fichier descriptif des flux des données mémorisés dans le lac de données pour orchestrer les différents micro-services de la plateforme. Selon une autre particularité, le déploiement des modèles de données de contrôle de fraude est assuré par le biais d'un contrôleur de référentiel de 20 codes qui interroge le moteur de modélisation par rapport à certains référentiels de code pour détecter les modifications apportées au flux. Selon une autre particularité, tout déploiement en continu des modèles et algorithmes de contrôle, issus de l'environnement de 25 développement, dans l'environnement de production est supervisé par une personne. Selon une autre particularité, le système de redéploiement de données comprend des moyens pour implémenter et configurer un ensemble 30 d'apprentissage en ligne en fonction du modèle d'analyse de données. 3057378 5 Selon une autre particularité, le système de détection de fraude comprend un dispositif de contrôle pour analyser des informations, émises par la couche de traitement « temps réel » et contenant des évènements datés relatifs à des cas de fraude, et activer un signal d'alarme en cas de 5 détection de données frauduleuses afin d'alerter un administrateur ou un superviseur de la tentative de fraude. Selon une autre particularité, le système de détection de fraude est utilisé pour la sécurisation de données sensibles dans un système de 10 services comprenant au moins une base de données et au moins une plateforme de traitement de requêtes associées aux données sensibles, ledit système de détection de fraude jouant le rôle d'interface sécurisée entre la base de données et la plateforme de traitement de requête. 15 DESCRIPTION DES FIGURES ILLUSTRATIVES D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après, faite en référence aux dessins annexés, dans lesquels: 20 - la figure 1 représente le schéma de la structure du système de détection de fraude dans un mode de réalisation; - la figure 2 représente le schéma de l'utilisation de la structure du système de détection de fraude dans un système comprenant une base de données et une plateforme de traitement de requêtes associées à des 25 données sensibles, selon un mode de réalisation; - les figures 3a et 3b représentent respectivement les schémas de la structure de la plateforme du système de détection de fraude et de l'environnement de développement de la plateforme, selon un mode de réalisation; 30 - les figures 4a et 4b représentent respectivement les schémas de la structure de l'environnement de production de la plateforme et, de la couche 305 7 3 7 8 6 de traitement en « temps réel » et de l'ensemble d'apprentissage, selon un mode de réalisation; DESCRIPTION DES MODES DE REALISATION PREFERES DE 5 L'INVENTION La présente invention concerne un système (1, figure 1) pour détecter une action frauduleuse dans un flux de données. 10 Dans certains modes de réalisation, le système (1) de détection de fraude dans un flux de données comporte au moins un lac (4) de données permettant de stocker de gros volumes de données à structures variables, sous forme d'une base de données distribuée, pour des utilisations et 15 analyses diverses, une plateforme (10) qui contient au moins un environnement (3, figure 4a) de production comportant au moins une architecture matérielle et logicielle auto-adaptative comprenant une pluralité de modèles de contrôle de fraude mémorisés, un moteur de test et de mise à jour de modèles de contrôle de fraude, au moins une mémoire pour le 20 stockage de données, au moins un processeur, une couche (31, figures 1, 2 et 4a par exemple) de traitement en « temps réel » du flux de données et une couche (33) de service, lesdites couches étant reliées par un moyen de communication, chacune des couches comprenant au moins du matériel et du logiciel implémentant un micro-service exécuté sur le processeur de 25 l'architecture matérielle informatique pour permettre respectivement de vérifier et/ou contrôler en temps réel le flux de données et de gérer dans la couche (33) de service les données traitées, issues du traitement « temps réel », ladite architecture auto-adaptative étant caractérisée en ce qu'elle comprend également un ensemble (32) d'apprentissage en ligne relié à la 30 couche (31) de traitement en « temps réel » pour réentraîner et mettre à jour en temps réel des modèles de contrôle de fraude mémorisés dans la couche (31) de traitement en « temps réel ». 3057378 7 Le lac (4) de données est le référentiel ou système où sont stockées des données en provenance, par exemple et de manière non limitative d'une base de données. Différentes sources, par exemple et de manière non limitative un téléphone, un terminal de paiement ou une banque émettent en 5 continu un flux de données en direction de la plateforme (10) du système de détection de fraude qui procède alors au traitement, du flux de chaque source, pour vérifier si ledit flux contient des données frauduleuses ou non. Dans le cas où des données frauduleuses sont détectées, l'évènement est daté et contenu dans une information émise par la couche (31) de traitement 10 en «temps réel». Ladite information est ensuite transférée dans un dispositif de contrôle qui active un signal d'alarme qui peut être, par exemple et de manière non limitative, un son ou un message, pour avertir un administrateur ou un superviseur d'une tentative de fraude. Dans le cas où aucune fraude n'est détectée dans le flux de données, les données sont transférées pour 15 exploitation. L'architecture matérielle informatique de l'architecture auto-adaptive comprend au moins un moteur de calcul distribué, de préférence un cluster de calcul. Le calcul distribué consiste à repartir un calcul ou un traitement sur plusieurs processeurs d'une architecture matérielle informatique, par 20 exemple une unité centrale informatique. Des instructions indépendantes peuvent ainsi être traitées en parallèle par les différents microprocesseurs. Les données sont traitées en temps réel dans l'environnement (3) de production de l'architecture auto-adaptative et plus précisément dans la couche « temps réel ». Les micro-services (m) de ladite couche, voir par 25 exemple figure 4b, sont des applications fonctionnelles autonomes de petites tailles avec un périmètre fonctionnel (c'est-à-dire la liste complète des fonctionnalités et leur description exhaustive) délimité. Les micro-services communiquent entre eux par échange de données ou messages via un système de file de messages, de préférence un intergiciel de messagerie de 30 type MQ (pour « message queue » en anglais). L'intergiciel de messagerie peut être avec ou sans broker. Un intergiciel MQ avec broker permet de traduire un message du protocole de messagerie formel du micro-service 3057378 8 expéditeur au protocole de messagerie formel du micro-service receveur dudit message. Dans le cas d'un MQ sans broker, le message est transmis d'un micro-service à un autre sans traduction dudit message. De préférence, le format des messages échangés entre les micro-services est indépendant 5 des différents protocoles de messagerie formels des micro-services, afin de permettre l'interprétation desdits messages par les protocoles de messagerie desdits micro-services, et ce, quelque soit le langage utilisé par ces micro-services. Par exemple et de manière non limitative, les formats JSON (Notation Objet issue de JavaScript) et/ou XML (langage de balisage 10 extensible) peuvent être utilisés. Une interface de programmation, par exemple et de manière non limitative une interface API REST, est utilisée dans l'architecture pour l'orchestration des micro-services et pour les fonctions supports. Les fonctions supports, qui sont également des micro-services, sont des 15 fonctions mises en oeuvre pour le bon fonctionnement de la plateforme (10) de contrôle, par exemple et de manière non limitative la mise à jour de configuration ou la mise à jour des paramètres des modèles de contrôle. Ces fonctions supports répondent aux besoins non fonctionnels de la plateforme et n'implémentent pas un périmètre fonctionnel donné. 20 Par besoin non fonctionnel, on entend tout besoin relatif au bon fonctionnement de la plateforme. L'interface de programmation d'applications (API REST) basée sur l'architecture REST (Representational State Transfer en anglais) est adaptée pour les systèmes de données distribués. L'architecture ou interface API 25 REST: - est orienté client-serveur, c'est-à-dire que les responsabilités sont séparées entre un client et un serveur. Cela permet aux deux entités (client et serveur) d'évoluer indépendamment; - est sans état, c'est-à-dire que chaque requête du client vers le 30 serveur doit contenir toute l'information nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre d'un contexte conservé sur le serveur. Cela 3057378 9 augmente les interactions d'un client avec le serveur, mais réduit l'adhérence du client par rapport à une instance de service; - possède une mémoire cache: le serveur envoie une réponse 5 qui donne l'information sur la propension de cette réponse à être mise en mémoire cache, comme la fraîcheur, sa date de création, si elle doit être conservée dans le futur. Cela permet aux clients de ne pas faire de requêtes inutiles et également d'améliorer l'extensibilité des serveurs; 10 - est une interface uniforme, pour laquelle chaque donnée ou ressource est identifiée, chaque donnée ou ressource étant manipulé à travers une représentation définie qui lui est associée et chaque message transmis est auto-descriptif, c'est-à-dire qu'il possède les informations qui permettent de le 15 décrire; - possède une structure en couche: les états d'une application sont identifiés par des ressources individuelles. Toute l'information n'est pas envoyée dans une seule ressource unique. Les requêtes/réponses entre le client et le serveur 20 augmentent et donc peuvent faire baisser la performance d'où l'importance de la mise en cache. La structure en couche permet ainsi de rendre beaucoup plus flexible l'évolution du système; - peut être, en option, de type « code à la demande » (code-on- 25 demand en anglais), c'est-à-dire que les clients ont la possibilité d'exécuter des scripts obtenus depuis le serveur. Cela permet d'éviter que le traitement ne se fasse que du côté serveur et permet donc de faire évoluer les fonctionnalités du client au cours du temps. 30 La structuration de l'architecture auto-adaptative, et en particulier la couche de traitement (31) en «temps réel », en micro-services (m) permet de 3057378 10 découper la chaîne de traitement des flux de données en un nombre N donné de micro-services (m), ledit nombre N correspondant au nombre de types de traitement à effectuer pour répondre à une requête. Par exemple et de manière non limitative, si le type de traitement à réaliser concerne le 5 calcul d'agrégats sur les transactions d'un porteur de carte sur les vingt- quatre dernières heures chez un type de marchand, un seul micro-service (m) est mis à contribution pour effectuer le calcul. Si l'on souhaite calculer les agrégats sur les quarante-huit dernières heures, alors un second micro-service est mis à contribution. Cette architecture de type micro-services (m), 10 basée sur du passage de messages, permet de multiplier le nombre d'instances d'un type de service donné pour permettre notamment le passage à l'échelle, dans le cas où l'on souhaite interrompre une instance, c'est-à-dire l'interruption du flux de données en direction de ladite instance, pour effectuer une configuration donnée, par exemple pour recharger ses 15 paramètres. Par architecture de type micro-services, on entend une architecture logicielle à partir de laquelle un ensemble complexe d'applications est décomposé en plusieurs processus indépendants et faiblement couplés, dénommés micro-services (m) et communiquant entre eux via un système 20 message, par exemple une API. Par instance de service on entend un modèle de contrôle de fraude ou d'analyse de données ou de calcul. Chaque micro-service est particulièrement, au moins, en charge de la mise en route et du fonctionnement (par exemple les fonctions supports) d'au 25 moins un modèle ou programme de contrôle de fraude. L'apprentissage ou entraînement des modèles consiste à l'estimation des paramètres permettant de décrire correctement un processus en fonction des données d'entrée. Par exemple et de manière-non limitative, le paramètre à estimer peut être le poids ou coefficient des variables ou 30 données d'entrées. Le poids d'une variable ou une donnée d'entrée, défini(e) par une valeur réelle, détermine l'importance de la variable ou donnée 3057378 11 d'entrée: plus le poids de la variable ou donnée est importante plus la variable ou donnée d'entrée est influente dans la description du processus. Plusieurs modèles de contrôle de fraude existent, parmi lesquels ont trouve principalement, par exemple et de manière non limitative, le modèle 5 des forêts aléatoires (Random Forest en anglais), le modèle des réseaux de neurones, le modèle des règles expertes ou le modèle d'exploration de graphe (graph mining en anglais). Dans un mode de réalisation, le modèle des forêts aléatoires peut être utilisé. Les forêts aléatoires sont des ensembles d'arbres de décisions, chaque arbre se distinguant des autres par 10 le sous-échantillon de données, en provenance du flux de données issu par exemple d'un terminal bancaire ou toute autre source et, sur lequel il est entraîné. Un arbre de décision ou arbre décisionnel est une structure servant à prédire les valeurs prises par une variable en fonction d'un jeu de variables appelées variables ou données d'entrée. L'arbre décisionnel se présente 15 sous la forme d'une hiérarchie dont chaque élément est appelé noeud, le noeud initial étant appelé racine. Chaque noeud correspond à une décision quant à la valeur de la variable à prédire, par exemple le poids d'une donnée dans la détection de la fraude, la décision étant prise en fonction de la valeur des données d'entrée. A l'issu de l'apprentissage, une estimation des 20 paramètres importants pour la détection de fraudes dans le cas du modèle des forêts aléatoires consiste alors, par exemple, à moyenner les estimations en provenance des différents arbres de décisions. Dans un autre mode de réalisation le modèle du réseau de neurones peut être utilisé. Les réseaux de neurones, mettent en oeuvre le principe 25 d'induction, c'est-à-dire par l'expérience. Par confrontation avec des situations ponctuelles, un réseau de neurones va inférer un système de décision intégré dont le caractère générique est fonction du nombre de cas d'apprentissages rencontrés et de leur complexité par rapport à la complexité du problème rencontré. Les réseaux de neurones jouent un rôle important 30 dans plusieurs domaines allant de la classification d'espèces animales ou de phénomènes physiques à l'amélioration des techniques d'enseignement en passant par la reconnaissance de motifs dans le traitement d'images. En 3057378 12 particulier, les réseaux de neurones sont beaucoup utilisés dans le traitement de problèmes de nature statistiques, c'est-à-dire des problèmes faisant appel au traitement d'un très grand nombre de données. Par exemple et de manière non limitative les réseaux de neurones peuvent aider dans la prise 5 de décision concernant un achat boursier. Le réseau de neurones est constitué de structure nommée neurone formel. Ledit neurone formel est conçu comme un automate doté d'au moins une entrée, d'une sortie et d'une fonction de transfert qui transforme les données en entrée en données en sortie selon des règles précises. Par exemple et de manière non limitative, 10 un neurone peut sommer les données en entrées, comparer la somme résultante à une valeur seuil, et répondre en émettant un signal si cette somme est supérieure ou égale à ce seuil. Les données d'entrée, issues par exemple des terminaux, sont considérées comme des variables d'entrée et arrivent au noeud, chacune avec un poids donné appelé poids de connexion 15 ou coefficient synaptique. Ledit coefficient est un paramètre important dans la description de l'efficacité de la transmission des signaux d'un neurone à un autre. La phase d'apprentissage dans le cas d'un modèle basé sur les réseaux de neurones va consister, par exemple, à déterminer les poids synaptiques permettant d'obtenir une efficacité optimale. Une fois entraîné, le 20 réseau de neurones est en mesure de détecter les fraudes en fonctions des règles définissant les critères de fraudes. Si le réseau de neurones fonctionne avec des nombres réels, la réponse traduit une probabilité de certitude. Par exemple et de manière non limitative, si le processus consiste à déterminer si une donnée rentrée par un utilisateur est frauduleuse, le 25 résultat du réseau de neurones peut être: 1 pour « la donnée rentrée par l'utilisateur est frauduleuse », 0 pour « la donnée n'est pas frauduleuse » ou 0.7 pour « la donnée est presque sûrement frauduleuse », auquel cas le modèle peut être réentraîné pour être plus précis. Dans un autre mode de réalisation, le modèle de règles expertes peut 30 être utilisé pour la détection de fraudes. Dans ce cas, le modèle utilise une base de données de faits, essentiellement constituée d'évènements relatifs à des cas de fraude déjà rencontrés par exemple, et une base de règles pour 305 73 78 13 effectuer un raisonnement afin de produire de nouveaux faits ou évènements jusqu'à la détection de la fraude. Dans un autre mode de réalisation, le modèle utilisé pour la détection de fraude est le modèle d'exploration de graphe. Un graphe est un réseau ou 5 ensemble de noeuds, appelés sommets, reliés entre eux par au moins un segment (appelé arête) ou une flèche (appelée arc). Un arbre décisionnel est par exemple un cas particulier d'un graphe. Le flux de données en entrée est distribué sur l'ensemble des noeuds du graphe. L'exploration du graphe consiste alors à faire traverser le graphe par les données en appliquant le 10 poids de chaque arête ou arc ainsi que les fonctions d'activation, par exemple les fonctions sigmoïdes, associées à chaque noeud. La fonction d'activation du noeud fait la somme pondérée des données en entrée et retourne le résultat en sortie. L'exploration des noeuds se fait de proche en proche à partir d'un noeud initial au moyen d'un algorithme afin de trouver 15 des motifs ou caractéristiques selon des critères fixés au préalable et d'en extraire le maximum de connaissances permettant de détecter les fraudes. Les données traitées et qui ne contiennent pas d'informations frauduleuses sont ensuite stockées dans au moins une mémoire de la 20 couche de service (33) avant d'être transférées pour exploitation. Dans certains modes de réalisation, une sortie de la couche (31) « temps réel » est connectée à l'entrée de l'ensemble (32) d'apprentissage en ligne et la sortie de l'ensemble (32) d'apprentissage est reliée à une 25 entrée de la couche (31) de traitement en « temps réel » pour former une structure d'apprentissage en boucle, comme représenté sur les figures 1, 2 ou 4a par exemple. L'utilisation d'une structure en boucle dans l'architecture auto-adaptative permet une adaptation des modèles de contrôles aux flux de 30 données émis en temps réel et réduit de manière efficace le risque qu'un modèle géré par un micro-service (m) donné ne soit pas adapté pour contrôler les données contenues dans ledit flux. Une telle situation peut 3 0 5 7 3 7 8 14 rendre, en effet, le système (1) plus vulnérable aux fraudes. L'architecture auto-adaptative offre ainsi un avantage en comparaison à une architecture de type « lambda-architecture ». En effet une « lambda-architecture », tout comme l'architecture auto-adaptative, permet de traitement de données 5 massives et est constituée de trois couches. Ladite architecture comprend une couche de traitement en « temps réel », une couche de service et une couche de « traitement par lot » (batch processing en anglais). La couche de « traitement par lot », en général connectée à un lac de données et à la couche de service, joue le même rôle que l'ensemble (32) d'apprentissage 10 de modèles de contrôles à la différence que l'apprentissage des modèles ne se fait pas en temps réel. Les modèles sont, en effet, reparamétrés ou remplacés une fois pendant une période définie, par exemple et de manière non limitative une fois par jour ou une fois par mois en fonction des besoins. Les données sur lesquels ces modèles ont été paramétrés ne sont donc pas 15 actualisées en continu. Ce qui est un inconvénient lorsque l'on veut, en temps réel, adapter les modèles de contrôle aux changements des informations contenus dans le flux de données, pour empêcher une action frauduleuse. 20 Dans certains modes de réalisation, l'ensemble (32) d'apprentissage en ligne comprend des micro-services (m), comme représenté sur la figure 4b, chacun en charge de réentraîner des modèles de contrôle de fraude déployés dans la couche (31) de traitement en « temps réel », et un système (320) de redéploiement pour redéployer automatiquement les modèles de 25 contrôle de fraude réentraînés et mis à jour dans les micro-services (m) de la couche (31) de traitement en « temps réel » en charge de leur utilisation. Lorsque les paramètres d'un modèle de contrôle de fraude, pris en charge par un micro-service donné de la couche de traitement (31) « temps réel », doivent être mis à jour, le système (320) de redéploiement en temps 30 réel est utilisé plutôt que l'arrêt du micro-service afin de pouvoir assurer un traitement dans les délais impartis. Le système (320) de redéploiement comprend un service central qui reçoit une notification en provenance du 3057378 15 d'un micro-service, compris dans l'ensemble (32) d'apprentissage et en charge de l'entraînement d'un modèle de contrôle, lorsque ledit modèle a été réentraîné. Le service central du système (320) de redéploiement notifie à son tour les micro-services (m) de la couche (32) de traitement en « temps 5 réel » qui sont concernés, par la mise à jour des paramètres, via une API REST, qui rechargera les paramètres dans un serveur (310) de configuration, compris dans la couche de traitement en « temps réel ». Ledit serveur (310) distribuera alors les paramètres aux micro-services (m) concernés. Les paramètres des modèles de contrôle de fraude gérés par les 10 micro-services (m) de la couche de traitement « temps réel » (31) sont, ainsi, mis à jour en continu par le serveur (310) de configuration. Ainsi, à l'aide du système (320) de redéploiement, l'indisponibilité d'une instance de service due à la mise à jour d'un modèle dans un micro-service en cours d'exécution, passe de quelques secondes à quelques 15 millisecondes, permettant ainsi d'optimiser la gestion des messages. Le système (320) de redéploiement de données comprend, en outre, des moyens pour implémenter et configurer un ensemble d'apprentissage (32) en ligne en fonction du modèle d'analyse de données. Par exemple et de manière non limitative, si un ou plusieurs modèles de contrôle de fraude sont 20 utilisés, par exemple les modèles de forêts aléatoires et de réseau de neurones, le système (320) active un programme dont l'implémentation sur un processeur de l'architecture matérielle informatique permet de découper et configurer deux sous-ensembles d'apprentissage, composée chacune des micro-services (m) de l'ensemble d'apprentissage principale, les micro- 25 services (m) étant en charge soit de l'apprentissage du modèle de forêts aléatoires soit de l'apprentissage du modèle du réseau de neurones. Dans certains modes de réalisation, le système (1) de détection de fraude comprend également un environnement (2) de développement en 30 temps réel de nouveaux modèles de contrôle et/ou vérification de fraude du flux de données dans l'environnement (3) de production. 3057378 16 En général l'environnement de développement est séparé de l'environnement de production. Cette configuration, même si elle permet de sécuriser le système, manque de réactivité. En effet les données qui servent à tester les modèles de contrôle de fraude ne sont pas mises à jour en 5 continu, il n'est alors pas exclu qu'au moins un modèle, développé dans l'environnement (2) de ne parvienne pas à prend en compte certains critères pour détecter une fraude quelconque, une fois qu'il est utilisé dans l'environnement (3) de production. L'environnement (2) de développement de la présente invention permet, ainsi, d'avoir un système sécurisé et réactif aux 10 changements du flux de données, comme nous le verrons dans la suite de la description. Dans certains modes de réalisation, l'environnement (2) de développement comporte une architecture matérielle informatique et 15 logicielle de déploiement composée d'au moins un moteur (21) de modélisation pour développer et tester les modèles de contrôle, ledit moteur (21) de modélisation étant relié à un moteur (20) de calcul distribué « map/reduce » configuré pour charger des données de production dans l'environnement (2) de développement et permettre l'évaluation en temps 20 réel de nouveaux modèles de contrôle et, un déployeur (22) de flux de données en charge du déploiement des modèles dans le flux de données pris en charge dans l'environnement (3) de production. Le moteur de calcul distribué « map/reduce » comprend au moins une unité matérielle informatique de découpage pour découper le flux de 25 données lues en entrée en petits volumes et à les distribuer dans une première série d'unités matérielles informatiques aptes à effectuer des calculs parallèles. Chaque unité de calcul de la première série, met en oeuvre une fonction dite « map » qui consiste à émettre les données lues en entrée sous forme de paires (clé, valeur). Une clé, est un élément compris dans la 30 donnée. Par exemple et de manière non limitative, si la donnée consiste en une phrase, les mots qui composent la phrase peuvent être définis comme des clés. La valeur, quant à elle, est un chiffre, par exemple 1 ou 2. Elle peut 3057378 17 servir à définir la quantité d'élément qui compose une clé, par exemple. Lorsque les paires (clé, valeur) ont été émises, elles sont transférées en direction d'une seconde série d'unités matérielles informatiques de calcul parallèle. Les unités de calcul de cette seconde série mettent alors en oeuvre 5 une fonction dite « reduce » qui consiste à regrouper les paires ayant des clés identiques et à les stocker dans une mémoire. Les données sont alors chargées à partir de ladite mémoire dans le moteur de modélisation, pour le développement de modèles de calcul en fonctions des paires (clé, valeur). 10 Dans certains modes de réalisation, le déployeur (22) de flux de données utilise un fichier descriptif des flux des données, mémorisé dans le lac de données, pour orchestrer les différents micros-services de la plateforme (10). Lorsqu'un flux de données est chargé dans le lac de données, à partir d'une base de données par exemple, les informations 15 relatives au flux de données sont automatiquement inscrits dans le fichier descriptif dudit flux de données ainsi que leur adresse, c'est-à-dire la couche de traitement où lesdites données doivent être acheminées. Le déployeur (22) lit les différentes adresses inscrites dans le fichier descriptif et transfère les données dans les micro-services correspondant. 20 Dans certains modes de réalisation, le déploiement des modèles de données de contrôle de fraude est assuré par le biais d'un contrôleur de référentiel de codes qui interroge le moteur (21) de modélisation par rapport à certains référentiels de code pour détecter les modifications apportées au 25 flux. Dans certains modes de réalisation, tout déploiement en continu de modèles et algorithmes de contrôle, issus de l'environnement (2) de développement, dans l'environnement (3) de production peut être supervisé 30 par une personne selon le cas d'usage du système (1) de détection. Cette action peut être effectuée pour éviter qu'un modèle ou code malicieux soit introduit dans l'environnement (3) de production. Par exemple et de manière 305 7 3 7 8 18 non limitative, lorsque le système (1) de détection est utilisé pour le contrôle d'informations relatives à une carte bancaire et à son utilisateur, le processus de contrôle peut se dérouler dans le cadre d'une norme de sécurité telle que le standard PCI DSS (norme de sécurité de l'industrie des cartes de 5 paiement). Ce standard permet d'augmenter le contrôle des informations du titulaire de la carte dans le but de réduire l'utilisation frauduleuse des instruments de paiement. Un superviseur peut, dans ce cadre, effectuer une vérification des modèles ou codes de contrôle afin de détecter toute tentative de modification des informations relatives à un utilisateur particulier, par 10 exemple. Dans certains modes de réalisation, le système (1) de détection de fraude pour la sécurisation de données sensibles dans un système de services (5) comprenant au moins une base (52) de données et au moins 15 une plateforme (53) de traitement de requêtes associées aux données sensibles, ledit système (1) de détection de fraude jouant le rôle d'interface sécurisée entre la base (52) de données et la plateforme (53) de traitement de requête. Par exemple et de manière non limitative, le système (5) de services (figure 2), peut comprendre une interface client (50) au moyen 20 duquel un client entre des données pour avoir accès à un service particulier compris dans une plateforme (51) de services. Les données entrées par le client sont enregistrées dans une base (52) de données puis transférées vers le lac (4) de données du système (1) de détection de fraude. Les données sont ensuite acheminées vers la couche (31) de traitement en « temps réel » 25 pour analyse. Si les données contiennent des éléments frauduleux le dispositif d'alarme du système (1) de détection envoie un signal à un superviseur pour l'informer de la tentative de fraude. Si au contraire les données ne sont pas frauduleuses le résultat de la requête est transféré dans la couche (33) de service. La plateforme (53) de traitement de requête 30 du système (5) de services effectue un appel du résultat et procède au traitement de la requête du client. 3057378 19 La présente demande décrit diverses caractéristiques techniques et avantages en référence aux figures et/ou à divers modes de réalisation. L'homme de métier comprendra que les caractéristiques techniques d'un 5 mode de réalisation donné peuvent en fait être combinées avec des caractéristiques d'un autre mode de réalisation à moins que l'inverse ne soit explicitement mentionné ou qu'il ne soit évident que ces caractéristiques sont incompatibles ou que la combinaison ne fournisse pas une solution à au moins un des problèmes techniques mentionnés dans la présente demande. 10 De plus, les caractéristiques techniques décrites dans un mode de réalisation donné peuvent être isolées des autres caractéristiques de ce mode à moins que l'inverse ne soit explicitement mentionné. Il doit être évident pour les personnes versées dans l'art que la 15 présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes, et 20 l'invention ne doit pas être limitée aux détails donnés ci-dessus. REVENDICATIONS1. Système (1) informatique de détection de fraude dans un flux de données comportant au moins un lac (4) de données permettant de stocker de gros volumes de données à structures variables, sous forme d'une base de données distribuée, pour des utilisations et analyses diverses, une plateforme (10) qui contient au moins un environnement (3) de production comportant au moins une architecture matérielle et logicielle auto-adaptative comprenant une pluralité de modèles de contrôle de io fraude mémorisés, un moteur de test et de mise à jour de modèles de contrôle de fraude, au moins une mémoire pour le stockage de données, au moins un processeur, une couche (31) de traitement en « temps réel » du flux de données et une couche (33) de service, lesdites couches étant reliées par un moyen de communication, chacune des couches 15 comprenant au moins du matériel et du logiciel implémentant un micro- service exécuté sur le processeur de l'architecture matérielle informatique pour permettre respectivement de vérifier et/ou contrôler en temps réel le flux de données et de gérer dans la couche (33) de service les données traitées, issues du traitement « temps réel », ladite architecture auto- 20 adaptative étant caractérisée en ce qu'elle comprend également un ensemble (32) d'apprentissage en ligne relié à la couche (31) de traitement en « temps réel » pour réentraîner et mettre à jour en temps réel des modèles de contrôle de fraude mémorisés dans la couche (31) de traitement en « temps réel ». 25 2. Système (1) de détection de fraude dans un flux de données selon la revendication 1, caractérisé en ce qu'une sortie de la couche (31) « temps réel » est connectée à l'entrée de l'ensemble (32) d'apprentissage en ligne et la sortie de l'ensemble (32) d'apprentissage est reliée à une entrée de la couche (31) de traitement en « temps réel » pour former une 30 structure d'apprentissage en boucle. 3057378 2 3. Système (1) de détection de fraude dans un flux de données selon la revendication 1, caractérisé en ce que l'ensemble (32) d'apprentissage en ligne comprend des micro-services (m), chacun en charge de réentraîner des modèles de contrôle de fraude déployés dans la s couche (31) de traitement en « temps réel », et un système (320) de redéploiement pour redéployer automatiquement les modèles de contrôle de fraude réentraînés et mis à jour dans les micro-services (m) de la couche (31) de traitement en « temps réel » en charge de leur utilisation. 4. Système (1) de détection de fraude dans un flux de donnés selon io la revendication 1, caractérisé en ce que la couche de traitement en « temps réel » comprend un serveur (310) de configuration pour mettre à jour en continu les paramètres des modèles de contrôle de fraude gérés par les micro-services (m) de ladite couche de traitement en « temps réel » (31). 15 5. Système (1) de détection de fraude dans un flux de données selon les revendications 4 et 5, caractérisé en ce que le système (320) de redéploiement de l'ensemble (32) d'apprentissage en ligne comprend un service central apte à recevoir une notification en provenance d'un micro-service dudit ensemble (32) d'apprentissage lorsqu'un modèle a été 20 réentraîné, ledit service central notifiant à son tour les micro-services (m) de la couche (31) de traitement en « temps réel » qui sont concernés par la mise à jour des paramètres, via une API REST qui rechargera les paramètres dans le serveur (31) de configuration de la couche (31) de traitement en « temps réel », ledit serveur (310) distribuant alors les 25 paramètres aux micro-services (m) concernés. 6. Système (1) de détection de fraude dans un flux de données selon la revendication 1, caractérisée en ce que la structuration de l'architecture auto-adaptative en micro-services (m), communiquant entre eux par passage de messages, permet de découper la chaîne de 30 traitement des flux de données, en un nombre N donné de micro-services (m), ledit nombre N correspondant au nombre de types de traitement à 3057378 3 effectuer pour répondre à une requête donnée, et de multiplier le nombre d'instances d'un type de service donné pour permettre un passage à l'échelle et assurer la continuité de service dans le cas où une instance est interrompue pour effectuer une configuration donnée. 5 7. Système (1) de détection de fraude dans un flux de données selon la revendication 1, caractérisé en ce qu'il comprend également un environnement (2) de développement de nouveaux modèles de contrôle et/ou vérification de fraude du flux de données dans l'environnement (3) de production. 8. Système (1) de détection de fraude dans un flux de données selon la revendication précédente, caractérisé en ce que l'environnement (2) de développement comporte une architecture matérielle informatique et logicielle de déploiement composée d'au moins un moteur (21) de modélisation pour développer et tester les modèles de contrôle, ledit moteur (21) de modélisation étant relié à un moteur (20) de calcul distribué « map/reduce » configuré pour charger des données de production dans l'environnement (2) de développement et permettre l'évaluation en temps réel de nouveaux modèles de contrôle et, un déployeur (22) de flux de données en charge du déploiement des modèles dans l'environnement (3) de production. 9. Système (1) de détection de fraude dans un flux de données selon la revendication précédente, caractérisé en ce que le déployeur (22) de flux de données utilise un fichier descriptif des flux des données mémorisés dans le lac de données pour orchestrer les différents micro- services de la plateforme (10). 10. Système (1) de détection de fraude dans un flux de données selon les revendications précédentes, caractérisé en ce que le déploiement des modèles de données de contrôle de fraude est assuré par le biais d'un contrôleur de référentiel de codes qui interroge le moteur (21) 3057378 4 de modélisation par rapport à certains référentiels de code pour détecter les modifications apportées au flux. 11.Système (1) de détection de fraude dans un flux de données selon les revendications précédentes, caractérisé en ce que tout 5 déploiement en continu de modèles et algorithmes de contrôle, issus de l'environnement (2) de développement, dans l'environnement (3) de production est supervisé par une personne. 12.Système (1) de détection de fraude dans un flux de données selon la revendication 3, caractérisé en ce que le système (320) de 10 redéploiement de données comprend des moyens pour implémenter et configurer un ensemble d'apprentissage (32) en ligne en fonction du modèle d'analyse de données. 13.Système (1) de détection de fraude dans un flux de données selon la revendication 1, caractérisé en ce qu'il comprend un dispositif de 15 contrôle pour analyser des informations, émises par la couche (31) de traitement « temps réel » et contenant des évènements datés relatifs à des cas de fraude, et activer un signal d'alarme en cas de détection de données frauduleuses afin d'alerter un administrateur ou un superviseur de la tentative de fraude. 20 14.Utilisation du système (1) de détection de fraude, selon une des revendications 1 à 13, pour la sécurisation de données sensibles dans un système (5) de services comprenant au moins une base (52) de données et au moins une plateforme (53) de traitement de requêtes associées aux données sensibles, ledit système (1) de détection de fraude jouant le rôle 25 d'interface sécurisée entre la base (52) de données et la plateforme (53) de traitement de requête.