Brevet FR3094518A1 — publié le 20201002

Description Titre de l'invention : Procédé de détection de bots dans un réseau d'utilisateurs Domaine technique [0001] La présente invention concerne un procédé de détection de bots dans un réseau d'utilisateurs. Technique antérieure [0002] De façon connue en elle-même, un bot informatique, plus simplement appelé « bot », désigne un agent logiciel automatique ou semi-automatique se faisant passer pour un humain dans un réseaux d'utilisateurs. [0003] De tels bots peuvent être notamment programmés pour déstabiliser le fonctionnement d'un réseau d'utilisateur, par exemple en spammant le réseau. [0004] Pour se prémunir contre de tels problèmes, l'organisateur d'un réseau d'utilisateurs a donc tout intérêt à détecter de tels bots. [0005] Il est par exemple connu de demander à un titulaire d'un compte d'accès à un réseau social de fournir des pièces justificatives attestant qu'il est bien humain. Toutefois, un tel mécanisme est fastidieux. [0006] Il a également envisagé de recourir à la biométrie pour discriminer utilisateurs humains et bots dans un réseau social. Cette idée présente toutefois l'inconvénient d'être relativement complexe de mise en oeuvre pour l'organisme qui gère le réseau d'utilisateur, et de requérir du matériel très spécialisé (capteurs biométriques). Or, certains utilisateurs du réseau ne disposent pas toujours de ce matériel, si bien qu'un tel procédé n'est pas généralisable à toute situation. Exposé de l'invention [0007] Un but de l'invention est de détecter des bots dans un réseau d'utilisateurs d'une manière qui soit simple et efficace. [0008] Il est à cet effet proposé, selon un premier aspect de l'invention, un procédé de détection de bots dans un réseau d'utilisateurs, le procédé comprenant des étapes de : réception par un terminal utilisateur d'un identifiant associé à un compte d'utilisateur du réseau ; transmission, par le terminal utilisateur, de l'identifiant à un système de contrôle d'accès configure pour déterminer si un détenteur du terminal mobile a le droit ou non d'accéder à une zone ou à un service, la zone ou le service étant indépendant du réseau d'utilisateurs ; transmission, par le système de contrôle d'accès à un serveur, d'une donnée représentative du fait que l'identifiant a été reçue par le système de contrôle d'accès ; et utilisation par le serveur de la donnée représentative pour déterminer si l'utilisateur du compte associé à l'identifiant est un bot ou non. 2 [0009] La donnée représentative du fait que l'identifiant a été reçue par le système de contrôle d'accès à une zone sécurisée ou un service sécurisé révèle indirectement que le détenteur du terminal mobile a tenté d'obtenir un accès à la zone sécurisée ou au service sécurisé. Dc plus, cet identifiant est associé en propre à un compte d'utilisateur du réseau. Ainsi, cette donnée constitue un indice du fait que le titulaire de cc compte est bien un humain ; c'est pourquoi l'utilisation dc cette donnée est pertinente pour décider si cc titulaire est un bot ou non. En fait, l'invention met astucieusement à profil une situation ne pouvant être effectuée que par un humain, à savoir demander l'accès à une zone sécurisée ou à un service sécurisé indépendant du réseau d'utilisateurs, pour discriminer humains et bots dans cc réseau d'utilisateurs. [0010] Le procédé selon le premier aspect de l'invention peut également comprendre les ca- ractéristiques optionnelles définies dans les revendications dépendantes, prises seules ou combinées en elles lorsque cela est techniquement possible. [0011] Dc préférence, les étapes dc transmission sont répétées, et dans lequel les données transmises au serveur sont indicatives d'une fréquence à laquelle l'identifiant a été reçue par le système de contrôle d'accès. [0012] Dc préférence, le compte d'utilisateur définit un identifiant de connexion permettant à un utilisateur de se connecter au réseau, et dans lequel l'identifiant reçu par le terminal utilisateur est un identifiant secondaire différent de l'identifiant de connexion. [0013] Dc préférence, l'identifiant reçu par le terminal est une donnée ayant une durée de validité temporaire. [0014] De préférence, le terminal utilisateur reçoit plusieurs identifiants qui sont toutes associés au même compte d'utilisateur du réseau, mais qui sont respectivement associés à des systèmes de contrôle d'accès à des zones ou services différents, les étapes de transmission sont mises en oeuvre pour chaque identifiant et le système de contrôle d'accès associé à cet identifiant, le serveur utilisant chaque donnée représentative transmise par un système de contrôle d'accès pour déterminer si l'utilisateur du compte utilisateur est un bot ou non. [0015] De préférence, les identifiants sont différents les uns des autres. [0016] De préférence, des niveaux de confiance différents assignés aux différents systèmes de contrôle d'accès sont également utilisés par le serveur pour déterminer si l'utilisateur du compte utilisateur est un bot ou non. [0017] De préférence, des données indicatives des positions géographiques des zones sont également utilisés par le serveur pour déterminer si l'utilisateur du compte utilisateur est un bot ou non. [0018] Par exemple, la zone considérée est un bâtiment, une partie de bâtiment et/ou donne accès à un moyen de transport. Le service considéré peut être un service bancaire, par exemple un retrait d' argent liquide ou une transaction bancaire. 3 [00191 De préférence, le réseau d'utilisateurs est administré par une infrastructure comprenant le serveur mais ne comprenant pas le système de contrôle d'accès. [0020] De préférence, une donnée représentative du fait que l'identifiant a été reçue par un système de contrôle d'accès est transmise au serveur de sorte que le système de contrôle d'accès reste anonyme par rapport au serveur. [0021] Tl est également proposé, selon un deuxième aspect de l'invention, un système pour la détection de bots dans un réseau d'utilisateurs, le système comprenant un serveur, un terminal utilisateur et un système de contrôle d'accès configuré pour déterminer si un détenteur du terminal mobile a le droit ou non d'accéder à une zone ou un service, la zone ou le service étant indépendant du réseau d'utilisateurs, dans lequel le terminal utilisateur est configure pour recevoir au moins un identifiant associé à un compte d'utilisateur du réseau et transmettre l'identifiant au système de contrôle d'accès ; le système de contrôle d'accès est en outre configuré pour transmettre au serveur une donnée représentative du fait que l'identifiant a été reçue par le système de contrôle d'accès ; et le serveur est configuré pour utiliser la donnée représentative pour déterminer si l'utilisateur du compte associé à l'identifiant est un bot ou non. Brève description des dessins [0022] D'autres caractéristiques, buts et avantages de l'invention ressortiront de la des- cription qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels : [0023] [fig.1] [0024] [fig.2] [0025] Les figures 1 et 2 illustrent de façon schématique un système pour détecter des bots dans un réseau d'utilisateurs. [0026] [fig.3] [0027] La figure 3 est un organigramme d'étapes d'un procédé de détection de bots dans un réseau d'utilisateurs, selon un mode de réalisation de l'invention. [0028] Sur l'ensemble des figures, les éléments similaires portent des références identiques. Description des modes de réalisation [00291 En référence à la figure 1, un système pour détecter des bots dans un réseau d'utilisateurs R comprend un serveur 1, un terminal utilisateur 2, et au moins un système de contrôle d'accès 3. [00301 Le serveur 1 fait partie d'une infrastructure donnant à des utilisateurs accès au réseau R. Le réseau d'utilisateurs R est par exemple une plateforme de réseautage social connectée à Internet, plateforme que l'on appelle communément « réseau social ». [00311 Le terminal utilisateur 2 a vocation à être détenu par un utilisateur humain du réseau R. Il peut par exemple être un smartphone, un ordinateur portable, ou hien une carte à puce. [0032] Par ailleurs, le système de contrôle d'accès 3 a pour fonction de contrôler l'accès d'un utilisateur à une zone ou à un service. La zone ou le service est indépendant(e) du réseau d'utilisateurs R. [0033] En particulier, le système de contrôle d'accès 3 ne fait pas partie de l'infrastructure qui gère le réseau d'utilisateurs R. [0034] En référence à la figure 2, le serveur 1 comprend typiquement une interface dc com- munication 10, une unité de traitement de données 12, et une mémoire 14. [0035] L'interface de communication 10 est reliée à Internet. [0036] L'unité de traitement 12 comprenant par exemple au moins un processeur configuré pour exécuter un programme d'ordinateur. [0037] L'unité de traitement 12 a pour fonction de gérer des comptes d'utilisateurs de ce réseau d'utilisateurs R. Le serveur 1 peut par exemple être configuré pour enrôler dc nouveaux utilisateurs, c'est-à-dire leur créer des comptes leur permettant d'accéder au réseau d'utilisateurs R. Un compte définit notamment pour un utilisateur nouvellement enrôlé un identifiant de connexion et un mot de passe. [0038] L'unité de traitement 12 peut également être configurée pour contrôler l'accès d'utilisateurs au réseau d'utilisateurs R ou certains services de cc réseau. Lors d'un tel contrôle, le serveur 1 vérifie si un identifiant de connexion et un mot de passe saisis par un utilisateur souhaitant accéder au réseau d'utilisateurs R correspondent bien à un compte préalablement créé. [0039] L'unité de traitement 12 a par ailleurs pour fonction de détecter des bots dans le réseau d'utilisateurs R. On verra par la suite que l'unité de traitement 12 se fonde sur des données particulières pour décider si le titulaire d'un compte s'avère être un bot ou pas. [0040] Par ailleurs, le terminal utilisateur 2 comprend par ailleurs une première interface de communication 20 pour communiquer avec le serveur 1, une deuxième interface de communication 22 pour communiquer avec le ou chaque système de contrôle d'accès 3, une mémoire 24 et une unité de traitement de données 26. [0041] La première interface de communication 20 peut être configurée pour accéder à Internet. Elle est de préférence de type radio sans fil, par exemple cellulaire (30/40/50) ou Wi-Fi. [0042] La deuxième interface de communication 22 est également de préférence de type radio sans fil. La première interface de communication 20 et la deuxième interface de communication 22 peuvent en réalité être une seule et même interface de communication. En variante, la deuxième interface de communication 22 est d'un type différent de la première interface de communication 20. Par exemple, la deuxième interface est de type communication en champ proche (NFC) ou Bluetooth. [0043] La mémoire 24 est non volatile, par exemple de type SSD, HDD, Flash, EEPROM, etc. Elle est adaptée pour mémoriser des données reçues par la première interface de communication 20. [0044] L'unité de traitement de données 26 est configurée pour commander ou participer à une communication de données avec le système de contrôle d'accès 3 via la deuxième interface de communication 22. [0045] L'unité de traitement de données 26 peut également exécuter une application jouant le rôle d'interface d'accès au réseau d'utilisateurs R. Un tel programme ou application peut par exemple être téléchargée sur une plateforme de téléchargement en ligne. [0046] Le système de contrôle 3 comprend une première interface de communication 30 pour communiquer avec le terminal utilisateur 2, une deuxième interface de communication 32 pour communiquer avec le serveur 1, une mémoire 34 et une unité de traitement de données 36. [0047] La première interface de communication 30 est du même type que la deuxième interface de communication 22 du terminal utilisateur 2. [0048] La deuxième interface de communication 32 est de type filaire (Ethernet) ou radio sans fil (Wi-Fi, Bluctooth, etc.). Elle peut être du même type que la première interface de communication 32 du terminal utilisateur 2. [0049] La mémoire 34 est non volatile, par exemple de type SSD, HDD, Flash, EEPROM, etc. Elle est adaptée pour mémoriser des données reçues par la première interface de communication 30. [0050] L'unité de traitement de données 36 comprend au moins un processeur. Elle est notamment configurée pour déterminer si un usager a le droit ou non d'accéder à une zone contrôlée par le système de contrôle d'accès 3, ou d'accéder à un service que le système est susceptible de rendre à un tel usager. [0051] Dans le cas d'un contrôle d'accès à une zone, le système de contrôle d'accès 3 peut en outre comprendre un portique (voir figure 1) susceptible d'être ouvert pour laisser une personne physique accéder à la zone concernée, ou d'être fermé pour empêcher la personne physique d'accéder cette zone. Dans ce cas, la première interface de communication 30 peut être incluse dans un tel portique, de sorte qu'une communication puisse être établie entre le terminal utilisateur 2 et le système de contrôle d'accès 3, lorsque le détenteur du terminal utilisateur 2 passe à proximité du portique. [0052] Par exemple, la zone concernée est une zone permettant d'accéder à un moyen de transport tel que train ou métro (auquel cas le portique se trouve en amont d'un quai) ou bien avion (auquel cas le portique se situe dans un aéroport). Dans un autre exemple, la zone est un bâtiment ou une partie de bâtiment. Le portillon peut alors se trouver dans le hall d'un immeuble. [0053] Dans le cas d'un contrôle d'accès à un service, ce service peut être un service 6 bancaire, par exemple un retrait d'argent liquide, auquel cas, le système de contrôle d'accès comprend un distributeur d'argent liquide, se trouvant par exemple en extérieur ou bien dans un bâtiment. [0054] Alternativement, le service peut être une transaction bancaire, auquel cas le système de contrôle comprend un terminal de paiement (Point Of Sale en anglais, généralement abrégé en POS) apte à communiquer avec un serveur bancaire. Un tel terminal de paiement est typiquement utilisé dans un commerce, par exemple une boutique, un restaurant, etc. [0055] Quel que soit le type d'accès considéré (à une zone ou à un service), cet accès n'est pas un accès au réseau d'utilisateurs R lui-même. [0056] Bien qu'un seul système de contrôle d'accès soit représenté sur les figures 1 et 2, il est entendu que le système de détection de bots dans le réseau d'utilisateurs R peut comprendre plusieurs systèmes de contrôle d'accès 3 contrôlant des accès à des zones ou services respectifs différents, chacun de ces systèmes 3 étant conforme à la description qui précède. [0057] En référence à la figure 3, un procédé pour détecter des bots dans le réseau d'utilisateurs R comprend les étapes suivantes. [0058] Dans une étape préliminaire, un utilisateur s'enrôle auprès du serveur 1, de sorte à adhérer au réseau d'utilisateurs R. Au cours de cet enrôlement, connu en lui-même, l'unité de traitement 12 génère pour cet utilisateur un compte comprenant un identifiant de connexion et un mot de passe, qui lui permettront ensuite d'accéder aux services du réseau d'utilisateurs R, par exemple depuis son terminal utilisateur 2, ou depuis un autre terminal. [0059] A ce stade, il existe une incertitude sur la nature de l'utilisateur enrôlé (personne physique ou bot). [0060] L'unité de traitement 12 du serveur 1 génère pour cet utilisateur au moins un autre identifiant ID que l'on nomme dans la suite « identifiant secondaire » pour le différencier de l'identifiant de connexion (étape 100). [0061] A la différence de l'identifiant de connexion, l'identifiant secondaire ID n'a pas destiné à être utilisé par l'utilisateur pour se connecter au réseau R. On ven-a dans la suite que cet identifiant secondaire ID sert indirectement à déterminer si l'utilisateur est un bot ou non. [0062] On suppose par ailleurs que le serveur 1 a détecté que le terminal utilisateur 2 ap- partient à l'utilisateur qui s'est enrôlé. Pour cela, le serveur 1 peut tout simplement identifier depuis quel dispositif une demande d'adhésion au réseau R (enrôlement) a été émise. Dans ce cas, l'existence du terminal utilisateur 2 peut être connue du serveur 1 dès l'enrôlement. Alternativement, une telle détection peut être effectué lorsqu'une application de connexion au réseau R installée sur le terminal utilisateur 2 est utilisée 7 par un détenteur de ce terminal pour tenter de se connecter au réseau R, en entrant son identifiant de connexion et son mot de passe. [0063] Par la suite, le terminal utilisateur 2 reçoit l'identifiant secondaire ID généré (étape 102). [0064] Par exemple, l'identifiant secondaire ID est transmis par le serveur 1 au terminal uti- lisateur 2 via un canal de communication établi entre les interfaces de communications 10 et 20. Cette transmission est par exemple demandée par l'application installée dans le terminal utilisateur 2, ou initiée spontanément par le serveur 1. Alternativement, le terminal utilisateur obtient l'identifiant secondaire ID par un autre canal, faisant intervenir un équipement tiers par exemple. [0065] L'identifiant secondaire ID est mémorisé dans la mémoire 24 du terminal utilisateur 2. [0066] Ultérieurement, le détenteur du terminal utilisateur 2 se rapproche de la zone sécurisée contrôlée par le système de contrôle d'accès 3. Par exemple, si la zone sécurisée est une zone d'accès à un moyen de transport, ce détenteur se rapproche pour cela d'un portique lui barrant l'accès à ce moyen de transport. [0067] Pour ouvrir le portique, le détenteur rapproche son terminal utilisateur 2 du portique, de sorte que s'établisse une communication entre l'interface de communication 22 du terminal utilisateur 2 et l'interface de communication 30 du système de contrôle d'accès 3. [0068] L'unité de traitement 36 met en oeuvre une étape de contrôle d'accès durant laquelle elle détermine si le détenteur du terminal utilisateur 2 a le droit ou non d'accéder à la zone sécurisée, sur la base d'informations échangées avec le terminal utilisateur 2. [0069] Par exemple, dans le cas de l'accès à un moyen de transport, le terminal utilisateur 2 peut être censé constituer un titre de transport, au sens où il peut mémoriser des données représentatives d'un titre de transport dématérialisé. La communication établie entre le terminal utilisateur 2 et le système de contrôle d'accès 3 a pour but de déterminer si ce titre de transport est valable, c'est-à-dire si le possesseur du terminal mobile a ou non le droit d'accéder au moyen de transport. Si tel est le cas, le portique s'ouvre pour le laisser accéder à ce moyen de transport. Sinon le portique reste fermé. [0070] Concomitamment à ce contrôle d'accès, le terminal utilisateur 2 transmet au système de contrôle d'accès 3 l'identifiant secondaire ID qu'il avait préalablement mémorisé (étape 104). [0071] L'identifiant secondaire ID est ensuite mémorisé dans la mémoire 34 du système de contrôle d'accès 3. [0072] La date à laquelle l'identifiant secondaire ID a été transmis par le terminal utilisateur 2 au système est également mémorisée dans la mémoire 34, en association avec l'identifiant secondaire ID. 8 [0073] L'étape de transmission 104 est mise en oeuvre à chaque fois que le détenteur sollicite le système d'accès à la zone sécurisée, en vue d'y accéder. Par conséquent, l'identifiant secondaire ID peut se retrouver associé dans la mémoire à des dates différentes. [0074] L'unité de traitement 36 peut également mémoriser dans la mémoire 34 une donnée de résultat de contrôle d'accès (à savoir une donnée indiquant si le système de contrôle 3 a donné au détenteur du terminal mobile 2 un accès à la zone sécurisée). [0075] L'unité de traitement 36 du système de contrôle d'accès 3 génère au moins une donnée D représentative du fait que l'identifiant a été reçue par le système de contrôle d'accès 3. [0076] De préférence, les données D comprennent une fréquence à laquelle l'identifiant a été reçue par le système de contrôle d'accès 3, suite à plusieurs sollicitations du système de contrôle d'accès 3 à la zone sécurisée par le détenteur du terminateur utilisateur 2. Cette fréquence est représentative d'une fréquence à laquelle le détenteur du terminal utilisateur 2 a souhaité obtenir un accès à la zone sécurisée. [0077] Cette fréquence peut être calculée par exemple sous la forme d'un délai séparant deux mises en oeuvre successive de l'étape de transmission de l'identifiant secondaire ID par le terminal utilisateur 2 au système de contrôle d'accès 3, ou bien sous la forme d'un nombre de telles transmissions dans une période de temps de durée prédéterminée. [0078] Le système de contrôle d'accès 3 transmet au serveur 1 les données D représentatives du fait que l'identifiant a été reçue par le système de contrôle d'accès 3 (étape 106). [0079] De manière préférentielle, cette transmission est faite de telle façon que le système de contrôle d'accès 3 reste anonyme par rapport au serveur 1. Par « anonyme », on entend que le serveur 1 ne reçoit pas d'information lui permettant de déterminer l'accès (zone ou service) que contrôle le système de contrôle 3. Ceci est avantageux car est plus respectueux de la vie privée du possesseur du terminal 2 : il n'est en effet pas désirable que l'infrastructure qui administre le réseau d'utilisateurs ait à connaître des différents accès que demande ce possesseur. [0080] Le système de contrôle 3 peut également transmettre au serveur, en association avec la donnée D, l'identifiant ID. [0081] En revanche, le système de contrôle d'accès 3 ne transmet pas au serveur 1 les dates qu'il a mémorisées, de sorte à préserver la vie privée du détenteur du terminal utilisateur 2. [0082] Les étapes 100, 100, 104, 106 qui précèdent peut-être répétées pour plusieurs systèmes de contrôle d'accès 3 à des zones sécurisées différentes. Il est préférable dans ce cas que le serveur 1 génère des identifiants secondaires différents respectivement associés à ces systèmes de contrôle d'accès différents. Autant d'identifiants se- 9 condaires sont donc générés au cours de l'étape 100 qu'il existe de systèmes de contrôle d'accès à des zones sécurisées. Alternativement, un même identifiant secondaire ID peut être partagé entre plusieurs systèmes de contrôle d'accès 3 différents ; autrement dit, le nombre d'identifiants secondaires générés est dans ce cas inférieur au nombre de systèmes de contrôle d'accès 3. [0083] Le serveur 1 utilise les données qu'il reçoit via son interface de communication 10 d'au moins un système de contrôle d'accès 3 pour déterminer si le titulaire du compte utilisateur auquel l'identifiant secondaire ID est associé est un bot ou non (étape 108). [0084] Par exemple, dans un mode de réalisation particulièrement tolérant, le serveur 1 considère que ce titulaire n'est pas un bot dès qu'il reçoit du système de contrôle d'accès 3 une donnée représentative du fait que l'identifiant secondaire ID a été reçu par ce système de contrôle d'accès 3. [0085] Dans des modes de réalisation plus exigeants, le serveur 1 peut ne prendre la décision que le titulaire n'est pas un bot que lorsque davantage de conditions sont remplies. Le serveur 1 peut poser comme condition qu'une fréquence D remontée doivent être supérieure à un seuil prédéterminé. [0086] Le serveur 1 peut en outre poser comme condition que des données sont remontées par plusieurs systèmes de contrôles d'accès 3 à des zones sécurisées différentes plutôt qu'un seul. [0087] Ces conditions peuvent être utilisées alternativement ou bien être cumulées. [0088] Lorsque plusieurs systèmes de contrôle d'accès 3 sont utilisés, ces systèmes peuvent se voir affecter différents niveaux de confiance par le serveur 1. Le serveur 1 mémorise par exemple dans sa mémoire 14 les niveaux de confiance respectifs des différents systèmes de contrôle d'accès 3. Lorsqu'une donnée D représentative du fait que l'identifiant ID a été reçu par un système de contrôle d'accès 3 est transmise au serveur 1, cette donnée D est pondérée par le niveau de confiance affecté au système de contrôle d'accès 3 avant utilisation par le serveur 1 pour sa prise de décision quant à la nature de bot ou non du titulaire du compte associé à l'identifiant secondaire ID correspondant. [0089] Le serveur 1 peut également utiliser, pour sa prise de décision, des données in- dicatives des positions géographiques des différents systèmes de contrôle d'accès 3 sollicités et remontant au serveur 1 des données D. Ces positions géographiques peuvent être prédéterminées et mémorisées dans la mémoire du serveur 1. Alternativement, les systèmes de contrôle d'accès peuvent transmettre eux-mêmes au serveur 1 les données de position les concernant. [0090] Dans tous les cas, le serveur 1 peut décider que le titulaire du compte est un bot lorsque des données qui semblent contradictoires sont remontées par plusieurs systèmes de contrôle d'accès. Par exemple, il peut s'agir de deux fréquences d'accès élevées qui sont remontées par deux systèmes de contrôle d'accès pour lesquels l'étape 104 a eu lieu en deux endroits éloignés l'un de l'autre. Par exemple, le serveur 1 apprenant qu'un utilisateur demande un accès quotidien au métro de Paris et demande un accès quotidien au métro de Moscou pourra conclure que cet utilisateur est un bot. [0091] Voici un exemple dc liste d'informations qui peuvent être remontées, mémorisées dans la mémoire 14, et utilisées pour l'étape 108 dc prise dc décision, en relation avec un compte d'utilisateur donné. [0092] - Trois identifiants secondaires ID1, 1D2, 1D3 [0093] - Différents partenaires gérant des systèmes de contrôle d'accès différentes [0094] partenaire 1 : européen, de confiance haute [0095] partenaire 2 : européen, de confiance moyenne [0096] partenaire 3 : américain, de confiance haute [0097] -pour une période donnée : [0098] 1D1 : passages fréquents chez partenaire 1 [0099] 1D1 : passages quotidiens chez partenaire 2 [0100] 1D2 : un passage chez partenaire 3 [0101] 1D3 n'a jamais été utilisé [0102] De préférence, un identifiant secondaire ID généré par le serveur 1 est une donnée ayant une durée de validité temporaire. Au terme d'un délai prédéterminé, le serveur 1 génère un nouvel identifiant secondaire ID associé à un système de contrôle d'accès 3 à une zone ou un service, et le transmet au terminal utilisateur 2. [0103] Quelle que soit la politique adoptée par le serveur 1 pour décider si le titulaire d'un compte est un bot ou non, le serveur 1 peut prendre des décisions n'ayant des effets que sur une période de temps limitée Par exemple, le serveur 1 parvenant à la conclusion que le titulaire d'un compte n'est pas un bot, du fait qu'il a sollicité tel ou tel système de contrôle d'accès 3 à une zone ou un service, peut suspendre ses vérifications concernant ce titulaire pendant une période prédéterminée. Une fois cette période écoulée, le serveur 1 peut examiner à nouveau si le titulaire est un bot ou non. A l'inverse, le serveur 1 parvenant à la conclusion que le titulaire d'un compte est un bot peut bannir ce titulaire du réseau d'utilisateurs R (c'est-à-dire l'empêcher d'accéder à des services du réseau d'utilisateurs R) pendant une période prédéterminée. Une fois cette période écoulée, le serveur 1 peut réexaminer à nouveau si le titulaire est un bot ou non. [0104] Bien entendu, l'invention ne se limite pas aux modes de réalisations décrits pré- cédemment. Notamment : [0105] - Il n'est pas nécessaire que le serveur 1 prenant une décision quant à la nature d'un utilisateur (bot ou non) soit également celui qui enrôle des utilisateurs. Il suffit que le serveur 3 puisse avoir accès à une mémoire mémorisant les comptes d'utilisateurs du 11 réseau. [0106] - L'invention n'est pas limitée au cas d'un réseau social ; elle est applicable à tout réseau auquel des utilisateurs peuvent accéder moyennant un compte d'utilisateur, derrière lequel un bot est susceptible de se cacher : site de jeu en ligne, site de rencontres, etc. [0107] - Il n'est pas nécessaire qu'un serveur 3 et le serveur 1 communiquent entre eux di- rectement par un canal de communication direct. Unc donnée peut être remontée par un système de contrôle d'accès 3 au serveur 1 par l'intermédiaire d'un système tiers. 12 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] REVENDICATIONSProcédé de détection de bots dans un réseau d'utilisateurs (R), le procédé comprenant des étapes de : - réception (102) par un terminal utilisateur (2) d'un identifiant (ID) associé à un compte d'utilisateur du réseau, - transmission (104), par le terminal utilisateur (2), de l'identifiant (ID) à un système de contrôle d'accès (3) configure pour déterminer si un détenteur du terminal mobile a le droit ou non d'accéder à une zone ou à un service, la zone ou le service étant indépendant du réseau d'utilisateurs (R), - transmission (106), par le système de contrôle d'accès (3) à un serveur (1), d'une donnée représentative du fait que l'identifiant (ID) a été reçue par le système de contrôle d'accès (3), - utilisation (108) par le serveur (1) de la donnée représentative pour déterminer si l'utilisateur du compte associé à l'identifiant (ID) est un bot ou non. Procédé selon la revendication 1, dans lequel les étapes de transmission (104, 106) sont répétées, et dans lequel les données transmises au serveur (1) sont indicatives d'une fréquence à laquelle l'identifiant (ID) a été reçue par le système de contrôle d'accès (3). Procédé selon l'une des revendications précédentes, dans lequel le compte d'utilisateur définit un identifiant de connexion permettant à un utilisateur de se connecter au réseau, et dans lequel l'identifiant (ID) reçu par le terminal utilisateur (2) est un identifiant secondaire différent de l'identifiant de connexion. Procédé selon l'une des revendications précédentes, dans lequel l'identifiant (ID) reçu par le terminal est une donnée ayant une durée de validité temporaire. Procédé selon l'une des revendications précédentes, dans lequel le terminal utilisateur (2) reçoit plusieurs identifiants (ID) qui sont toutes associés au même compte d'utilisateur du réseau, mais qui sont respectivement associés à des systèmes de contrôle d'accès à des zones ou services différents, les étapes de transmission sont mises en oeuvre pour chaque identifiant (ID) et le système de contrôle d'accès (3) associé à cet identifiant (ID), le serveur (1) utilisant chaque donnée représentative transmise par un système de contrôle d'accès (3) pour déterminer si l'utilisateur du compte utilisateur est un bot ou non. 13 [Revendication 6] Procédé selon la revendication 5, dans lequel les identifiants (TD) sont différents les uns des autres. [Revendication 7] Procédé selon l'une des revendications 5 et 6, dans lequel des niveaux de confiance différents assignés aux différents systèmes de contrôle d'accès sont également utilisés par le serveur (1) pour déterminer si l'utilisateur du compte utilisateur est un bot ou non. [Revendication 8] Procédé selon l'une des revendications 5 à 7, dans lequel des données indicatives des positions géographiques des zones sont également utilisés par le serveur (1) pour déterminer si l'utilisateur du compte utilisateur est un bot ou non. [Revendication 9] Procédé selon l'une des revendications précédentes, dans lequel : - la zone est un bâtiment, une partie de bâtiment et/ou donne accès à un moyen de transport, ou - le service est un service bancaire, par exemple un retrait d'argent liquide ou une transaction bancaire. [Revendication 10] Procédé selon l'une des revendications précédentes, dans lequel le réseau d'utilisateurs est administré par une infrastructure comprenant le serveur (1) mais ne comprenant pas le système de contrôle d'accès. [Revendication 11] Procédé selon l'une des revendications précédentes, dans lequel une donnée représentative du fait que l'identifiant (TD) a été reçue par un système de contrôle d'accès (3) est transmise au serveur (1) de sorte que le système de contrôle d'accès (3) reste anonyme par rapport au serveur (1). [Revendication 12] Système pour la détection de bots dans un réseau d'utilisateurs (R), le système comprenant un serveur (1), un terminal utilisateur (2) et un système de contrôle d'accès (3) configuré pour déterminer si un détenteur du terminal mobile a le droit ou non d'accéder à une zone ou un service, la zone ou le service étant indépendant du réseau d'utilisateurs (R), dans lequel - le terminal utilisateur (2) est configuré pour : recevoir au moins un identifiant (ID) associé à un compte d'utilisateur du réseau et transmettre l'identifiant (ID) au système de contrôle d'accès (3), - le système de contrôle d'accès (3) est en outre configuré pour transmettre au serveur (1) une donnée représentative du fait que l'identifiant (ID) a été reçue par le système de contrôle d'accès (3), - le serveur (1) est configuré pour utiliser la donnée représentative pour déterminer si l'utilisateur du compte associé à l'identifiant (ID) est un bot ou non.