FR 3110727 A1 20211126 FR 2005028 A 20200519 La présente invention concerne l’identification et la détermination d’un ordre d’un sous-ensemble d’événements d’un ensemble d’événements, chaque événement étant sélectionnable par un utilisateur et étant associé à un instant, à une catégorie et à des éléments, selon au moins un historique de sélections d’événements. Après avoir obtenu un arbre associant des événements dont au moins un instant appartient à une période de temps donnée, les événements de l’arbre étant associés les uns aux autres par leur catégorie et/ou leurs éléments selon des chemins comprenant au moins un nœud formé d’événements, de catégories ou d’éléments, et obtenu un historique de sélections comprenant des événements préalablement sélectionnés, un sous-ensemble d’événements reliés à un événement appartenant à l’historique de sélections via un chemin est identifié, les instants des événements identifiés étant postérieurs aux événements de l’historique de sélections. Un ordre des événements du sous-ensemble est ensuite déterminé. Procédé, dispositif et programme d’ordinateur pour identifier et ordonner des événements sélectionnables par un utilisateur L’invention se rapporte à l’identification et la détermination d’un ordre d’événements d’un ensemble d’événements, pour permettre à un utilisateur d’accéder facilement et rapidement à des événements susceptibles de l’intéresser, selon un historique de sélection. L’invention s’applique notamment en domaine des jeux en ligne, en particulier des paris sportifs. Depuis quelques années, les jeux accessibles via un réseau de communication, à travers une interface homme-machine, connaissent un très grand succès. A titre d’illustration, le nombre de joueurs faisant des paris « en ligne » sur des compétitions sportives a été multiplié par plus que trois ces cinq dernières années. Ainsi, par exemple, un joueur peut, à l’aide de son ordinateur, de sa tablette ou de son smartphone, accéder, via internet, à un portail d’un fournisseur de services proposant des jeux en ligne, sélectionner un match sur lequel il veut parier. A ces fins, il peut disposer d’un compte géré par le fournisseur de service qui peut alors accepter ou refuser les paris et gérer les gains et les pertes. Cependant, malgré ce succès, de nombreux joueurs sont réticents à utiliser de tels services du fait des difficultés rencontrées pour identifier les compétitions susceptibles de les intéresser. En effet, les catalogues des compétitions pouvant faire l’objet de paris sont généralement immenses. Ils peuvent comprendre une ou plusieurs centaines de compétitions journalières. Il est observé qu’il existe non seulement des compétitions par sport mais également des compétitions locales, régionales, nationales ou internationales, des compétitions pour amateurs ou professionnels, des compétitions selon des classes prédéterminées, etc. Ainsi, même en sélectionnant un sport particulier, il est souvent très difficile d’accéder rapidement aux compétitions recherchées. Le joueur perd ainsi des occasions de jeux et de gains. En outre, les joueurs utilisent de plus en plus souvent des dispositifs mobiles tels que des smartphones, pourvus d’écrans de petites tailles et de moyens d’interactions limités, ne comprenant notamment généralement pas de clavier. Rechercher des compétitions avec de tels dispositifs s’avère souvent particulièrement difficile. Il existe donc un réel besoin pour un système d’analyse et d’identification d’événements susceptibles d’intéresser un utilisateur, par exemple des compétitions sportives sur lesquelles un utilisateur peut engager des paris à distance, à l’aide d’un ordinateur, afin que cet utilisateur puisse identifier et sélectionner rapidement, à l’aide d’une interface simple, les événements qui l’intéressent et, le cas échéant, puisse engager une action, par exemple un pari. La présente invention vise notamment à résoudre ces problèmes. A cet effet, l’invention propose un mécanisme pour identifier et ordonner des événements afin de permettre à un utilisateur de sélectionner simplement et rapidement les événements qui l’intéressent. Il est ainsi proposé un procédé pour ordinateur pour identifier et ordonner un sous-ensemble d’au moins un événement d’un ensemble d’événements, chaque événement étant sélectionnable par un utilisateur et étant associé à au moins un instant, à au moins une catégorie et à au moins un élément, l’identification et la détermination d’un ordre d’événements étant effectués selon au moins un historique de sélections d’événements, le procédé comprenant : l’obtention d’au moins un arbre associant des événements dudit ensemble d’événements dont au moins un instant appartient à une période de temps donnée, les événements de l’au moins un arbre étant associés les uns aux autres par leur catégorie et/ou leur au moins un élément selon des chemins comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie et/ou au moins un élément ; l’obtention d’au moins un historique de sélections comprenant au moins un événement préalablement sélectionné ; l’identification, dans l’au moins un arbre obtenu, d’un sous-ensemble d’au moins un événement relié à au moins un événement appartenant à l’historique de sélections via un chemin comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie et/ou au moins un élément, les instants des événements identifiés étant postérieurs aux événements de l’au moins un historique de sélections ; et la détermination d’un ordre des événements du sous-ensemble d’au moins un événement. Le procédé selon l’invention permet ainsi de trier des événements pour identifier un nombre limité d’événements parmi un très grand nombre d’événements, permettant à un utilisateur d’accéder directement à des événements susceptibles de l’intéresser, l’autorisant à sélectionner rapidement des événements à partir d’un dispositif pourvu de ressources limitées, par exemple d’un écran de petite taille et de moyens de sélection limités. Selon un mode de réalisation particulier, la détermination d’un ordre des événements du sous-ensemble est effectuée selon une fréquence d’identification des événements du sous-ensemble d’au moins un événement dans l’au moins un arbre obtenu. Toujours selon un mode de réalisation particulier, l’identification, dans l’au moins un arbre obtenu, d’un sous-ensemble d’au moins un événement relié à au moins un événement appartenant à l’historique de sélections via un chemin est effectuée pour tous les événements de l’historique de sélections. Toujours selon un mode de réalisation particulier, l’identification, dans l’au moins un arbre obtenu, d’un sous-ensemble d’au moins un événement relié à au moins un événement appartenant à l’historique de sélections via un chemin est effectuée pour tous les chemins issus du au moins un événement appartenant à l’historique de sélections ou pour tous les chemins issus du au moins un événement appartenant à l’historique de sélections comprenant un nombre de nœuds inférieur à un seuil donné. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une mise à jour de l’au moins un arbre obtenu, la mise à jour comprenant la suppression d’au moins un instant associé à un événement, l’au moins un instant supprimé étant antérieur à un premier instant, ou l’ajout d’au moins un instant associé à un événement, l’au moins un instant ajouté étant antérieur à un second instant postérieur au premier instant. Toujours selon un mode de réalisation particulier, le procédé comprend en outre la sélection d’au moins une catégorie, les événements du sous-ensemble d’au moins un événement étant reliés à la au moins une catégorie sélectionnée par un chemin ne comprenant pas de nœud intermédiaire formé par une catégorie. Toujours selon un mode de réalisation particulier, la au moins une catégorie est sélectionnée selon la distribution des catégories des événements de l’historique de sélections. Toujours selon un mode de réalisation particulier, la au moins une catégorie est sélectionnée si la proportion des événements de l’historique de sélections liés à la au moins une catégorie est supérieure à un seuil donné. Toujours selon un mode de réalisation particulier, la au moins une catégorie est sélectionnée de façon aléatoire si la proportion des événements de l’historique de sélections liés à la au moins une catégorie est inférieure à un seuil donné. Toujours selon un mode de réalisation particulier, la au moins une catégorie est sélectionnée à partir de préférences d’un utilisateur déterminées à partir de l’historique de sélections d’événements. Toujours selon un mode de réalisation particulier, une pluralité d’événements de l’ensemble d’événements appartient à au moins un groupe, des événements de l’au moins un arbre étant associés les uns aux autres par leur catégorie, leur au moins un groupe et leur au moins un élément selon des chemins comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie, au moins un groupe ou au moins un élément. Toujours selon un mode de réalisation particulier, une pluralité de groupes appartient à au moins une classe, les événements de l’au moins un arbre étant associés les uns aux autres par leur catégorie, leurs groupes, la au moins une classe et leur au moins un élément selon des chemins comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie, au moins un groupe, au moins une classe ou au moins un élément. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de filtrage du sous-ensemble d’au moins un événement. Un programme informatique, mettant en œuvre tout ou partie du procédé décrit ci-dessus, installé sur un équipement préexistant, est en lui-même avantageux, dès lors qu’il permet d’accéder et sélectionner facilement et rapidement un événement susceptible d’intéresser un utilisateur. Ainsi, la présente invention vise également un programme informatique comportant des instructions pour la mise en œuvre du procédé précédemment décrit, lorsque ce programme est exécuté par un processeur. Ce programme peut utiliser n’importe quel langage de programmation (par exemple, un langage objet ou autre) et être sous la forme d’un code source interprétable, d’un code partiellement compilé ou d’un code totalement compilé. Un autre aspect concerne un support de stockage non-transitoire d’un programme exécutable par ordinateur, comprenant un ensemble de données représentant un ou plusieurs programmes, lesdits un ou plusieurs programmes comprenant des instructions pour, lors de l’exécution desdits un ou plusieurs programmes par un ordinateur comprenant une unité de traitement couplée de manière opérationnelle à des moyens mémoires et à un module d’interface entrées/sorties, pour exécuter tout ou partie du procédé décrit ci-dessus. D’autres caractéristiques, détails et avantages de l’invention apparaîtront à la lecture de la description détaillée ci-après. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés, dans lesquels : Fig. 1 illustre un exemple d’environnement dans lequel l’invention peut être mise en œuvre selon des modes de réalisation particuliers ; Fig. 2 illustre schématiquement l’architecture logique d’un moteur pour identifier et ordonner des événements susceptibles d’intéresser un utilisateur ; Fig. 3 illustre un exemple d’étapes du moteur pour identifier et ordonner des événements illustré sur la figure 2 ; Fig. 4 illustre un exemple d’étapes pour sélectionner des catégories à partir desquelles une recherche d’événements susceptibles d’intéresser un utilisateur peut être effectuée ; Fig. 5 illustre un exemple d’étapes pour l’obtention d’arbres d’événements à jour, comme décrit en référence à la figure 3 ; Fig. 6 illustre un exemple d’étapes pour ajouter des événements à un arbre d’événements relatif aux paris sportifs ; Fig. 7 illustre un exemple d’étapes pour parcourir un arbre d’événements et sélectionner des événements susceptibles d’intéresser un utilisateur, comme décrit en référence à la figure 3 ; Fig. 8 représente un exemple d’arbre d’événements liés à des paris sportifs reliant des équipes (éléments) à des matchs (événements) eux-mêmes reliés à des types de compétitions (groupes) qui, à leur tour sont reliés à des pays (classes) eux-mêmes reliés à des sports (catégories) ; Fig. 9 représente un extrait de l’arbre d’événements de la figure 8 ; Fig. 10 , comprenant les figures 10a à 10d, illustre un exemple de recherche d’événements futurs pouvant être proposés à un utilisateur, dans l’arbre d’événements illustré sur la figure 9, à partir d’un événement passé déjà sélectionné par l’utilisateur ; et Fig. 11 illustre un exemple de dispositif pouvant être utilisé pour mettre en œuvre, au moins partiellement, un mode de réalisation de l’invention, notamment des étapes décrites en référence aux figures 3 à 7. Description détaillée Selon des modes de réalisation de l’invention, des événements pouvant être sélectionnés par un utilisateur sont organisés dans un ou plusieurs arbres d’événements couvrant une période passée et future. Ces arbres sont filtrés selon des critères basés sur un historique de sélection de l’utilisateur et les résultats obtenus sont ordonnés afin de présenter à l’utilisateur des événements futurs susceptibles de l’intéresser, classés par ordre de pertinence. Les événements, qui reposent sur des éléments, peuvent être organisés en groupes, chaque groupe pouvant appartenir à une ou plusieurs classes qui peuvent elles-mêmes être organisées en catégories. A titre d’illustration, la description suivante est basée sur un exemple de paris sportifs, l’invention permettant de sélectionner et ordonner les compétitions susceptibles d’intéresser un joueur. Selon cet exemple, les événements peuvent être des matches, les éléments peuvent être des équipes, les groupes peuvent être des types de compétitions, les classes peuvent correspondre à des pays et les catégories peuvent être des sports. Cependant, il doit être compris que l’invention n’est pas limitée à cet exemple particulier. La figure 1 illustre un exemple d’environnement dans lequel l’invention peut être mise en œuvre selon des modes de réalisation particuliers. Comme représenté, un utilisateur pourvu d’un ordinateur personnel 100, d’une tablette 105 ou d’un smartphone 110 peut accéder, via un réseau de communication 115, par exemple internet, à un portail hébergé sur un serveur 120 d’un fournisseur de services. Il peut s’agir, par exemple, d’un portail web standard. Le fournisseur de services gère ici des jeux, par exemple des paris sur des compétitions dont des caractéristiques sont mémorisées dans une base de données d’un serveur de stockage 125, local ou distant. Le dispositif utilisé par l’utilisateur pour accéder au portail du fournisseur de services peut utiliser des moyens de communication filaires pour accéder au réseau de communication 115, par exemple des moyens de communication de type ADSL (pour Asymmetric Digital Subscriber Line en terminologie anglo-saxonne) ou des moyens de communication sans fil, par exemple des moyens de télécommunication de type 3G, 4G ou 5G. Un exemple d’architecture du dispositif 120 est illustré sur la figure 11. Selon des modes de réalisation particuliers de l’invention, lorsqu’un utilisateur accède au portail du fournisseur de services, un identifiant lui est demandé pour lui permettre d’accéder à son compte. L’utilisateur est ensuite, de préférence, authentifié, par exemple à l’aide d’un mot de passe ou de moyens biométriques tels que des moyens basés sur la reconnaissance de visages, d’iris ou d’empreintes digitales. Toujours selon des modes de réalisation particuliers de l’invention, un compte d’utilisateur permet de gérer des données personnelles de l’utilisateur (e.g. nom, prénom, lieu d’habitation, date de naissance, etc.), un profil (e.g. préférences en matière de jeux, de sports, de types de compétition, etc.) et/ou un porte-monnaie électronique que l’utilisateur peut approvisionner et utiliser pour jouer ou parier et pour retirer de l’argent gagné. De préférence, un historique des actions de l’utilisateur (e.g. la liste des jeux ou paris auxquels il a participé au cours d’une période écoulée, par exemple une période de 3 mois, avec des informations sur ces jeux ou paris) est en outre associé à son compte. A partir du portail du fournisseur de services et de son compte, un utilisateur peut effectuer des recherches sur les jeux et/ou compétitions à venir pour en sélectionner un ou plusieurs et jouer ou parier. Comme décrit ci-dessous, des modes de réalisation de l’invention visent à identifier et ordonner des jeux ou des paris, ou plus généralement des événements, pouvant être sélectionnés par un utilisateur, afin de simplifier et accélérer la recherche de tels événements. La figure 2 illustre schématiquement l’architecture logique d’un moteur pour identifier et ordonner des événements susceptibles d’intéresser un utilisateur. Comme illustré et selon des modes de réalisation particuliers de l’invention, le moteur pour identifier et ordonner des événements 200 peut utiliser, d’une part, un historique de sélections 205 d’un utilisateur ainsi que des préférences 210 de cet utilisateur et, d’autre part, un ou plusieurs arbres d’événements 215. Des exemples d’arbres d’événements sont décrits en référence aux figures 8, 9 et 10. De façon optionnelle, un module de recommandations générales peut être utilisé pour identifier et ordonner des événements lorsque l’historique de l’utilisateur et/ou ses préférences ne permettent pas d’identifier d’événements correspondant aux attentes de l’utilisateur, de façon pertinente. Le moteur pour identifier et ordonner des événements 200 génère une liste d’événements pertinents ordonnés permettant à un utilisateur d’identifier et sélectionner rapidement et simplement des événements susceptibles de l’intéresser, notamment à l’aide d’un dispositif pourvu de ressources limitées. La figure 3 illustre un exemple d’étapes du moteur pour identifier et ordonner des événements 200 illustré sur la figure 2. Les étapes illustrées sur la figure 3 peuvent notamment être mises en œuvre dans un dispositif du fournisseur de services, par exemple dans un module du serveur mettant en œuvre le portail d’accès. Comme illustré, une première étape a pour objet l’obtention d’un identifiant de l’utilisateur (étape 300), noté i . Cet identifiant permet d’accéder à des données propres à l’utilisateur, notamment à des préférences de l’utilisateur (étape 305) et à un historique des actions qu’il a engagées dans une période passée (étape 310). A titre d’illustration, en considérant le domaine des paris sportifs, les préférences de l’utilisateur peuvent comprendre un type de sport, par exemple le football, un type de compétitions, par exemple les matches de ligue 1 et les matches de coupe d’Europe ainsi qu’un pays, par exemple les matches joués en France et en Allemagne. L’historique des actions effectuées par un utilisateur comprend, par exemple, la liste des paris engagés par cet utilisateur. Un exemple d’une telle liste est donné en annexe (tableau 1). Elle comprend, de préférence, les caractéristiques des actions, par exemple, dans le domaine des paris sportifs, le match, les équipes en présence, le type de compétition, le pays où le match a eu lieu et le sport. La période couverte peut couvrir l’ensemble des actions effectuées ou peut être limitée pour éviter des données trop anciennes qui auraient peu ou n’auraient plus d’intérêt. Ainsi, par exemple, seules les données correspondant à une période prédéterminée, notée Δ t P , à partir de l’instant présent, noté t 0 , peuvent être prises en considération. Cette période est, de préférence, fixée par le fournisseur de services. Toujours à titre d’exemple, elle peut être de 3 mois. Une telle liste peut comprendre des indications supplémentaires, par exemple le nom de l’équipe gagnante, le montant parié par le joueur, les gains obtenus, etc. Dans une étape suivante, une ou plusieurs catégories sont sélectionnées (étape 315). Une telle catégorie est, par exemple, un type de sport. Comme décrit ci-dessous, notamment en référence à la figure 4, une ou plusieurs catégories peuvent être sélectionnées à partir des préférences d’un utilisateur et de son historique. En parallèle, avant ou après, un ou plusieurs arbres d’événements à jour sont obtenus (étape 320). Cette étape est décrite plus en détail ci-dessous, en référence aux figures 5 et 6. Une sélection ou un filtrage du ou des arbres obtenus est de préférence effectué pour sélectionner les arbres d’événements (ou portions d’arbres, considérés par la suite comme des arbres) pertinents (étape 325). Cette sélection ou ce filtrage peut consister, par exemple, à supprimer les arbres ou portions d’arbres d’événements qui ne sont pas associés aux catégories sélectionnées. De façon alternative, l’étape 320 peut être intégrée à l’étape 325 pour n’obtenir que les arbres correspondant aux catégories souhaitées. Le ou les arbres d’événements sélectionnés sont alors analysés, en particulier au regard de l’historique de l’utilisateur, pour identifier des événements pertinents, susceptibles d’intéresser l’utilisateur (étape 330). Ces événements sont ordonnés, du plus pertinent au moins pertinent, pour faciliter une éventuelle sélection par l’utilisateur. Un exemple d’étapes pour identifier des événements pertinents, susceptibles d’intéresser un utilisateur est décrit en référence à la figure 7. Les résultats obtenus peuvent être filtrés (étape 335), notamment par rapport aux préférences de l’utilisateur, pour écarter des événements potentiellement susceptibles de l’intéresser mais qu’il n’envisage pas de sélectionner, par exemple en raison du montant de la mise ou d’un niveau de risque. Les résultats sont ensuite transmis à un dispositif de l’utilisateur pour être affichés, permettant ainsi une sélection simple et rapide d’un ou plusieurs événements parmi un très grand nombre d’événements. La ou les sélections effectuées par l’utilisateur sont alors transmises au fournisseur de services, le cas échéant avec d’autres informations telles qu’un montant de pari. Le fournisseur de services peut effectuer des actions associées, par exemple engager des paris sur les événements sélectionnés. Une telle combinaison d’affichage et de sélection permet à un utilisateur d’utiliser sans difficulté un dispositif ayant des ressources limitées, notamment un écran de petite taille et des moyens de sélection limités. La figure 4 illustre un exemple d’étapes pour sélectionner des catégories à partir desquelles une recherche d’événements susceptibles d’intéresser un utilisateur peut être effectuée. Comme illustré, une première étape a pour objet de sélectionner l’ensemble des catégories sélectionnées par l’utilisateur i dans ses préférences, notée C_S(i, j) , où j représente un index des catégories (étape 400). Alternativement, seulement certaines des catégories sélectionnées par l’utilisateur i dans ses préférences peuvent être sélectionnées. A titre d’exemple, 10% des catégories sélectionnées par l’utilisateur i dans ses préférences peuvent être sélectionnées. Elles peuvent être sélectionnées de façon aléatoire. Dans une étape suivante, l’ensemble des catégories des événements sélectionnés par l’utilisateur i durant une période de temps passée Δ t P , notée C_H(i Δ t P , j) , où j représente un index des catégories, est obtenu (étape 405). Considérant l’exemple donné dans le tableau 1 en annexe et partant de l’hypothèse que les dates sont croissantes, que la date date_1 est hors de la période considérée (i.e. date_1 t 0 – Δ t P ) et que la date date_2 est dans la période considérée, l’ensemble des catégories obtenues comprend les catégories cat_1 et cat_7 . Dans une étape suivante, les catégories les plus significatives des catégories des événements sélectionnés par l’utilisateur i dans la période passée considérée sont sélectionnées (étape 410). A ces fins, la proportion de chaque catégorie obtenue, par rapport à l’ensemble des événements sélectionnés, est comparée à un seuil, noté θ. Il s’agit par exemple de chaque catégorie représentant plus de 15% des paris de l’utilisateur sur la période passée considérée. A nouveau, reprenant l’exemple du tableau 1 donné en annexe, seule la catégorie cat_1 , représentant 89% des paris, est sélectionnée (sur les 9 paris engagés sur la période considérée, 8 paris sont relatifs à la catégorie cat_1 , soit 8 / 9 x 100 = 89). La catégorie cat_7 , ne représentant que 11% des paris (un seul pari sur les 9 engagés), n’est pas sélectionnée. Dans une étape suivante, optionnelle, une ou plusieurs catégories peuvent être sélectionnées parmi les catégories des événements sélectionnés par l’utilisateur i dans la période passée considérée qui, ne comptant pas dans les catégories les plus significatives, n’ont pas été sélectionnées (étape 415). A titre d’illustration, il peut s’agir du tirage au sort d’une seule catégorie parmi les catégories obtenues à l’étape 405 qui n’ont pas été sélectionnées à l’étape 410 dès lors qu’une partie significative (par exemple plus de 30%) des catégories obtenues à l’étape 405 n’a pas été sélectionnée à l’étape 410. Cette sélection aléatoire peut également être réalisée à partir des catégories qui ne comptent pas dans les catégories les plus significatives (i.e. qui n’ont pas été sélectionnées à l’étape 410) mais dont la proportion, par rapport à l’ensemble des événements sélectionnés, est supérieure à un seuil, noté η. Il s’agit par exemple d’un tirage aléatoire sur les catégories dont chacune représente moins de 15% des paris de l’utilisateur sur la période passée considérée mais plus de 8%. L’ensemble des catégories sélectionnées aux étapes 400, 410 et 415 est noté C_P . La figure 5 illustre un exemple d’étapes pour l’obtention d’arbres d’événements à jour, comme décrit en référence à la figure 3. Comme illustré, une première étape a pour objet l’obtention d’un ou plusieurs arbres d’événements (étape 500). Il peut s’agir, par exemple, d’un arbre d’événements unique, comprenant l’ensemble des événements pouvant avoir fait l’objet d’une sélection dans la période passée considérée et l’ensemble des événements futurs pouvant être sélectionnés par un utilisateur. Il peut également s’agir de l’ensemble des arbres d’événements comprenant l’ensemble des événements pouvant avoir fait l’objet d’une sélection dans la période passée considérée et l’ensemble des événements futurs pouvant être sélectionnés par un utilisateur. Enfin, il peut s’agir d’un ou plusieurs arbres d’événements répondant à un ou plusieurs critères particuliers, par exemple le ou les arbres d’événements correspondant à une ou plusieurs catégories particulières (par exemple les catégories des événements à proposer à un utilisateur). Dans une étape suivante, il est déterminé si le ou les arbres sont à jour (étape 505). Cette détermination est, par exemple, basée sur une comparaison de la date de mise à jour du ou des arbres avec celle du jour. Si la date de mise à jour de tous les arbres d’événements est celle du jour, l’algorithme prend fin. Dans le cas contraire, chaque arbre d’événements dont la date de mise à jour est antérieure à la date du jour est mis à jour. Une telle mise à jour comprend, de préférence, la suppression des événements anciens, par exemple les événements n’appartenant pas à la période passée considérée ( Δ t P ), et l’ajout d’événements futurs pouvant être sélectionnés par un utilisateur. La période considérée pour les événements à ajouter peut se limiter à la date du jour ou peut comprendre la date du jour et des jours suivants. Cette période à laquelle appartiennent les événements futurs pouvant être sélectionnés par un utilisateur est notée Δ t F . Dans une étape suivante, tous les événements dont les dates sont antérieures à la période passée considérée ( t 0 – Δ t P ) sont sélectionnés dans l’arbre d’événements en cours de mise à jour (étape 510) afin d’être supprimés (étape 515). Selon certains modes de réalisation particuliers, la suppression comprend la simple suppression de la date ancienne associée à l’événement. Selon d’autres modes de réalisation, la suppression comprend la suppression de l’événement dans l’arbre d’événements (sous réserve que cet événement ne soit pas également associé à une date appartenant à la période passée considérée ou à la période future considérée). Ensuite, les événements à ajouter, dont les dates appartiennent à la période future considérée ( t 0 – Δ t F ) sont obtenus avec les informations associées (étape 520), par exemple des éléments, un groupe, une classe, une catégorie et une date. Ces événements peuvent alors être ajoutés à l’arbre d’événements (étape 525). Si l’événement existe déjà dans l’arbre d’événements, seule la nouvelle date est ajoutée. Dans le cas contraire, un événement est créé. La figure 6 illustre un exemple d’étapes pour ajouter des événements à un arbre d’événements relatif aux paris sportifs. Une première étape a pour objet de sélectionner le premier événement à ajouter (étape 600), ici un match, portant l’indice m ( m variant de 1 au nombre d’événements à ajouter) et d’obtenir les informations associées, par exemple la date, la catégorie (sport), la classe (pays où a lieu le match), le groupe (type de compétition) et les éléments (équipes). Après avoir obtenu ces données, un premier test est effectué pour déterminer si le match (événement) existe dans l’arbre d’événements (étape 605). En effet, certains matches se jouent régulièrement, par exemple tous les ans. Dans ce cas et selon certains modes de réalisation, un nouvel événement n’est pas créé en tant que tel mais une nouvelle date est ajoutée à un événement existant. Ainsi, si le match sélectionné existe dans l’arbre d’événements, la nouvelle date du match est ajoutée à cet événement (étape 610). Dans le cas contraire, si le match sélectionné n’existe pas dans l’arbre d’événements, il est créé. A ces fins et si l’arbre d’événements à mettre à jour est un arbre d’événements unique, un second test est effectué pour déterminer si le sport (catégorie) correspondant au match (événement) sélectionné existe dans l’arbre (étape 615). Si le sport correspondant au match sélectionné n’existe pas, il est créé (étape 620). Si plusieurs arbres d’événements sont utilisés, par exemple un arbre d’événements par sport, et s’il n’existe pas d’arbre d’événements associé au sport correspondant à l’événement sélectionné, un tel arbre est créé. Dans une étape suivante, un troisième test est effectué pour déterminer si le pays (classe) dans lequel se déroule le match (événement) sélectionné existe dans l’arbre (étape 625). Si le pays correspondant au match sélectionné n’existe pas, il est créé (étape 630). Dans une étape suivante, un quatrième test est effectué pour déterminer si la compétition (groupe) auquel appartient le match (événement) sélectionné existe dans l’arbre (étape 635). Si la compétition correspondant au match sélectionné n’existe pas, elle est créée (étape 640). Il est noté ici que selon des modes de réalisation particuliers un match peut compter dans différentes compétitions. Dans un tel cas et comme illustré avec une flèche en traits pointillés, les étapes 635 et 640 sont répétées autant de fois qu’il y a de compétitions différentes auxquelles appartient le match (l’index n est l’index des compétitions, il varie de 1 au nombre de compétitions auxquelles appartient le match). Dans une étape suivante, un cinquième test est effectué pour déterminer si les équipes (éléments) s’affrontant dans le match (événement) sélectionné existent dans l’arbre (étape 645). Comme illustré avec une flèche en traits pointillés, chaque équipe est traitée l’une après l’autre (l’index p est d’index des équipes, il varie de 1 au nombre d’équipes jouant dans le match). Si l’équipe considérée n’existe pas, elle est créée (étape 650). Enfin, le match sélectionné est ajouté à l’arbre d’événements et les liens entre le match, les éléments et les types de compétition sont créés (étape 655). S’ils n’existent pas, les liens entre les types de compétition, le pays et/ou le sport sont également créés. La date du match est ajoutée (étape 610). Les étapes illustrées sur le figure 6 sont répétées pour chaque événement à créer et/ou à mettre à jour. La figure 7 illustre un exemple d’étapes pour parcourir un arbre d’événements et sélectionner des événements susceptibles d’intéresser un utilisateur, comme décrit en référence à la figure 3. Selon des modes de réalisation particuliers de l’invention, tous les événements sélectionnés par un utilisateur dans une période passée considérée (e.g. tous les matches sur lesquels un joueur a engagé un pari au cours des trois derniers mois) sont utilisés comme événements de référence, dans un arbre d’événements, pour identifier des événements futurs susceptibles d’intéresser l’utilisateur. Un score pouvant correspondre au nombre d’identifications de l’événement futur peut être utilisé comme indicateur de pertinence. Toujours selon des modes de réalisation particuliers et pour limiter les traitements, les événements futurs susceptibles d’intéresser l’utilisateur peuvent être préfiltrés pour ne conserver que ceux qui sont, a priori, les plus pertinents. A ces fins, une distance exprimée en nombre de nœuds entre deux événements d’un arbre d’événements peut être utilisée. Tous les événements futurs, situés à une distance inférieure à un seuil donné, d’un événement de référence sont identifiés et un score, correspondant au nombre d’identifications de l’événement futur, est utilisé. Le seuil peut être prédéterminé, par exemple par le fournisseur de services, ou peut être déterminé dynamiquement, par exemple pour contrôler le nombre d’événements susceptibles d’intéresser un utilisateur identifié. Comme illustré sur la figure 7, une première étape a pour objet d’obtenir une liste de tous les événements sur lesquels un utilisateur i a engagé une action, notés évén_sélect(i,q) , appartenant à une catégorie sélectionnée ( C_P ), dans une période passée considérée (comprise entre l’instant présent t 0 et l’instant t 0 – Δ t P ), où q est un index sur les événements (étape 700). En considérant l’exemple présenté dans le tableau 1 en annexe, cette liste comprend les événements match_3 , match_C , match_B , match_5 , match_C , match_7 , match_11 et match_X (l’événement match_A ne fait pas partie de la liste car il n’appartient pas à la période de temps considérée et l’événement match_k ne fait pas partie de la liste car sa catégorie n’a pas été sélectionnée). Un degré de pertinence, ou score, est déterminé pour chacun des événements futurs (identifiés comme étant des événements à proposer) . Selon un mode de réalisation, cette détermination est effectuée en explorant tous les chemins partant de chaque événement de la liste d’événements établie à l’étape 700 (événement de référence) et en identifiant tous les événements futurs situés sur ces chemins (étape 705). Ces événements sont notés évén_prop(q,l), où l est index sur les chemins. Le score de chaque événement futur identifié est mis à jour (étape 710) afin de représenter le nombre d’identifications de cet événement (i.e. le nombre de chemins aboutissant à ce celui-ci). Selon un mode de réalisation particulier, seuls les événements futurs situés à une distance inférieure à un seuil donné, par exemple un seuil égal à 4, des événements de la liste d’événements établie à l’étape 700 sont identifiés comme étant des événements à proposer. Ainsi les scores peuvent être déterminés en explorant tous les chemins partant des événements considérés (événements de référence) ayant une longueur inférieure ou égale au seuil donné, en identifiant tous les événements futurs situés sur ces chemins (étape 705) et en mettant à jour le score de chaque événement futur identifié (étape 710) afin de représenter le nombre d’identifications de cet événement (i.e. le nombre de chemins aboutissant à ce celui-ci). Un premier test est ensuite effectué pour vérifier que tous les chemins partant d’un événement de la liste d’événements établie à l’étape 700 ont été analysés (étape 715). Lorsque tous les chemins partant d’un événement de la liste d’événements établie à l’étape 700 ont été analysés, un second test est effectué pour vérifier que tous les événements de la liste d’événements établie à l’étape 700 ont été utilisés comme événements de référence pour identifier des événements futurs (étape 720). Lorsque tous les événements de la liste d’événements établie à l’étape 700 ont été utilisés comme événements de référence pour identifier des événements futurs et que tous les chemins partant de chacun de ces événements ont été analysés, les événements futurs identifiés sont ordonnés selon leur score, du plus haut au plus bas, et, le cas échéant, selon d’autres critères (étape 725). Cette liste d’événements (ou une partie de celle-ci si un filtre est utilisé) peut alors être transmise à un utilisateur qui peut ainsi sélectionner rapidement les événements qui l’intéressent sans devoir effectuer une navigation longue et fastidieuse dans l’ensemble des événements futurs pouvant être sélectionnés. Comme décrit précédemment, le filtrage peut consister, par exemple, à supprimer les événements qui seraient associés à des mises supérieures à un certain montant ou qui seraient associés à un niveau de risque trop élevé. Il peut également consister à supprimer des événements qui seraient trop proches, dans le temps ou dans l’espace, les uns des autres. La figure 8 représente un exemple d’arbre d’événements liés à des paris sportifs reliant des équipes (éléments) à des matchs (événements) eux-mêmes reliés à des types de compétitions (groupes) qui, à leur tour sont reliés à des pays (classes) eux-mêmes reliés à des sports (catégories). La figure 9 représente un extrait de l’arbre d’événements de la figure 8. Comme illustré, un premier match M1 oppose les équipes E1 et E2 . Ce match, appartenant à la compétition C1 , est joué dans le pays P1 et concerne le sport S1 . De façon similaire, un second match M2 oppose les équipes E3 et E4 . Ce match, appartenant également à la compétition C1 , est aussi joué dans le pays P1 et concerne également le sport S1 . De façon similaire encore, un troisième match M3 oppose les équipes E4 et E5 . La compétition, le pays et le sport sont les mêmes que ceux des matches M1 et M2 . La figure 10, comprenant les figures 10a à 10d, illustre un exemple de recherche d’événements futurs pouvant être proposés à un utilisateur, dans l’arbre d’événements illustré sur la figure 9, à partir d’un événement passé déjà sélectionné par l’utilisateur. A titre d’illustration, l’événement passé déjà sélectionné par l’utilisateur est le match M3 (ou match_3 figurant dans le tableau 1 donné en annexe, match le plus ancien dans la période passée considérée) sur lequel l’utilisateur avait engagé un pari. Cet événement de référence est indiqué dans les figures 10a à 10d en trait gras continu. Toujours à titre d’illustration, il pourrait être considéré que la distance maximale entre l’événement passé de référence et un événement futur à proposer est par exemple égale à 2. Comme illustré sur la figure 10a, partant de l’événement M3 , il est possible, du fait du lien entre l’événement M3 et l’élément E5 , d’établir un chemin entre l’événement M3 et l’élément E5 . La longueur de ce chemin est égale à 1. L’élément E5 n’étant pas un événement, il ne peut être sélectionné pour être proposé à l’utilisateur. Le seul lien reliant l’élément E5 étant le lien entre l’événement M3 et l’élément E5 , le chemin se poursuit vers l’événement M3 , comme illustré avec les flèches. L’événement M3 étant un événement, il peut être proposé à l’utilisateur si, outre la date passée à laquelle l’utilisateur a engagé un pari, une date future est associée à cet événement. A titre d’illustration, il est supposé ici qu’une date future date_11 est associée à cet événement. Ce dernier est alors considéré comme un choix potentiel. Il est mémorisé avec sa date, son score et, de préférence, la longueur du chemin qui a permis de l’attendre, par exemple dans tableau tel que le tableau 2 donné en annexe. L’événement M3 peut ainsi être sélectionné de façon similaire par trois chemins distincts (i.e. les chemins M3-E5-M3 , M3-E4-M3 et M3-C1-M3 ). Le score associé est donc 3. La longueur moyenne des chemins est égale à 2 (2 + 2 + 2) / 3), comme indiqué dans le tableau 2. Comme illustré sur la figure 10b, partant de l’événement M3 , il est également possible, du fait du lien entre l’événement M3 et l’élément E4 , d’établir un chemin entre l’événement M3 et l’élément E4 puis entre ce dernier et l’événement M2 qui peut ainsi être sélectionné pour être proposé à l’utilisateur. De même, comme illustré sur la figure 10c, partant de l’événement M3 , il est également possible, du fait du lien entre l’événement M3 et la catégorie C1 , d’établir un chemin entre l’événement M3 et la catégorie C1 puis entre cette dernière et l’événement M2 qui peut ainsi être à nouveau sélectionné pour être proposé à l’utilisateur. L’événement M2 peut ainsi être sélectionné par deux chemins distincts (i.e. les chemins M3-E4-M2 et M3-C1-M2 ). Le score associé est donc 2. La longueur moyenne des chemins est égale à 2 (2 + 2) / 2), comme indiqué dans le tableau 2. De même, comme illustré sur la figure 10d, partant de l’événement M3 , il est également possible, du fait du lien entre l’événement M3 et la catégorie C1 , d’établir un chemin entre l’événement M3 et la catégorie C1 puis entre cette dernière et l’événement M1 qui peut ainsi être sélectionné pour être proposé à l’utilisateur. L’événement M1 peut ainsi être sélectionné par un seul chemin (i.e. le chemin M3-C1-M1 ). Le score associé est donc 1. La longueur du chemin est égale à 2, comme indiqué dans le tableau 2. Les résultats obtenus sont alors ordonnés pour pouvoir être transmis à l’utilisateur afin que celui-ci ait un accès rapide aux événements susceptibles de l’intéresser. Selon des modes de réalisation, les événements sont classés selon leur score puis, pour des scores égaux, par la longueur moyenne des chemins puis, pour des longueurs moyennes égales, par dates croissantes. Naturellement, d’autres critères peuvent être utilisés. Selon l’exemple illustré sur les figures 10a à 10d, les événements proposés à l’utilisateur sont, dans l’ordre : M3 , M2 et M1 . Il est observé ici que si une recherche systématique des événements à proposer à un utilisateur peut être effectuée sur la base de tous les événements qu’il a précédemment sélectionnés durant la période de temps passée considérée, en explorant tous les chemins possibles, d’autres approches sont possibles. Ainsi, par exemple, il est possible de n’utiliser qu’un sous-ensemble des événements précédemment sélectionnés par l’utilisateur durant la période de temps passée considérée, pouvant par exemple être déterminé de façon aléatoire, et/ou n’explorer que certains chemins, par exemple de façon aléatoire. La figure 11 illustre un exemple de dispositif pouvant être utilisé pour mettre en œuvre, au moins partiellement, un mode de réalisation de l’invention, notamment des étapes décrites en référence aux figures 3 à 7. Le dispositif 1100 est par exemple un serveur, un ordinateur ou un terminal. Le dispositif 1100 comporte de préférence un bus de communication 1102 auquel sont reliés : une unité centrale de traitement ou microprocesseur 1104 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; une mémoire morte 1106 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter le système d’exploitation et des programmes tels que "Prog" ; une mémoire vive ou mémoire cache 1108 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; et une interface de communication 1126 reliée à un réseau de communication distribué 1128, par exemple un réseau de communication sans fil et/ou un réseau de communication local, l'interface étant apte à transmettre et à recevoir des données, notamment vers et depuis un dispositif d’un utilisateur. Optionnellement, le dispositif 1100 peut également disposer des éléments suivants : un disque dur 1120 pouvant comporter les programmes "Prog" précités et des données traitées ou à traiter selon l’invention ; un clavier 1122 et une souris 1124 ou tout autre dispositif de pointage comme un crayon optique, un écran tactile ou une télécommande permettant à l’utilisateur d’interagir avec les programmes selon l'invention ; un lecteur 1110 de support amovible de stockage 1112 tel qu’une carte mémoire ou un disque, par exemple un disque DVD ; et une carte graphique 1114 reliée à un écran 1116. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 1100 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 1100 directement ou par l'intermédiaire d'un autre élément du dispositif 1100. Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en œuvre les processus selon l'invention peut être stocké, par exemple, dans le disque dur 1120 ou en mémoire morte 1106. Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 1128, via l'interface 1126, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 1100 avant d'être exécutés. L'unité centrale 1104 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 1120 ou dans la mémoire morte 1106 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 1120 ou la mémoire morte 1106, sont transférés dans la mémoire vive 1108 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en œuvre de l'invention. En fonction du mode de réalisation choisi, certains actes, actions, évènements ou fonctions de chacune des méthodes décrites dans le présent document peuvent être effectués ou se produire selon un ordre différent de celui dans lequel ils ont été décrits, ou peuvent être ajoutés, fusionnés ou bien ne pas être effectués ou ne pas se produire, selon le cas. En outre, dans certains modes de réalisation, certains actes, actions ou évènements sont effectués ou se produisent concurremment et non pas successivement. Bien que décrits à travers un certain nombre d’exemples de réalisation détaillés, le procédé proposé et l’équipement pour la mise en œuvre du procédé comprennent différentes variantes, modifications et perfectionnements qui apparaîtront de façon évidente à l’homme de l’art, étant entendu que ces différentes variantes, modifications et perfectionnements font partie de la portée de l’invention, telle que définie par les revendications qui suivent. De plus, différents aspects et caractéristiques décrits ci-dessus peuvent être mis en œuvre ensemble, ou séparément, ou bien substitués les uns aux autres, et l’ensemble des différentes combinaisons et sous combinaisons des aspects et caractéristiques font partie de la portée de l’invention. En outre, il se peut que certains systèmes et équipements décrits ci-dessus n’incorporent pas la totalité des modules et fonctions décrits pour les modes de réalisation préférés. Annexe événement date élément 1 élément 2 groupe classe catégorie match_A date_1 équipe_4 équipe_2 compétit_1 classe_1 cat_2 match_3 date_2 équipe_4 équipe_5 compétit_1 classe_1 cat_1 match_C date_3 équipe_1 équipe_2 compétit_1 classe_1 cat_1 match_B date_4 équipe_1 équipe_4 compétit_1 classe_1 cat_1 match_K date_5 équipe_2 équipe_15 compétit_5 classe_1 cat_7 match_5 date_6 équipe_2 équipe_5 compétit_1 classe_1 cat_1 match_C date_7 équipe_1 équipe_2 compétit_1 classe_3 cat_1 match_7 date_8 équipe_6 équipe_3 compétit_1 classe_1 cat_1 match_11 date_9 équipe_5 équipe_1 compétit_2 classe_2 cat_1 match_X date_10 équipe_3 équipe_9 compétit_1 classe_1 cat_1 événement date score longueur moyenne match_3 date_11 3 2 match_2 date_12 2 2 match_1 date_13 1 2 Procédé pour ordinateur pour identifier et ordonner un sous-ensemble d’au moins un événement d’un ensemble d’événements, chaque événement étant sélectionnable par un utilisateur et étant associé à au moins un instant, à au moins une catégorie et à au moins un élément, l’identification et la détermination d’un ordre d’événements étant effectués selon au moins un historique de sélections d’événements, le procédé comprenant : l’obtention d’au moins un arbre associant des événements dudit ensemble d’événements dont au moins un instant appartient à une période de temps donnée, les événements de l’au moins un arbre étant associés les uns aux autres par leur catégorie et/ou leur au moins un élément selon des chemins comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie et/ou au moins un élément ; l’obtention d’au moins un historique de sélections comprenant au moins un événement préalablement sélectionné ; l’identification, dans l’au moins un arbre obtenu, d’un sous-ensemble d’au moins un événement relié à au moins un événement appartenant à l’historique de sélections via un chemin comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie et/ou au moins un élément, les instants des événements identifiés étant postérieurs aux événements de l’au moins un historique de sélections ; et la détermination d’un ordre des événements du sous-ensemble d’au moins un événement. Procédé selon la revendication 1 selon lequel la détermination d’un ordre des événements du sous-ensemble est effectuée selon une fréquence d’identification des événements du sous-ensemble d’au moins un événement dans l’au moins un arbre obtenu. Procédé selon la revendication 1 ou la revendication 2 selon lequel l’identification, dans l’au moins un arbre obtenu, d’un sous-ensemble d’au moins un événement relié à au moins un événement appartenant à l’historique de sélections via un chemin est effectuée pour tous les événements de l’historique de sélections. Procédé selon l’une quelconque des revendications 1 à 3 selon lequel l’identification, dans l’au moins un arbre obtenu, d’un sous-ensemble d’au moins un événement relié à au moins un événement appartenant à l’historique de sélections via un chemin est effectuée pour tous les chemins issus du au moins un événement appartenant à l’historique de sélections ou pour tous les chemins issus du au moins un événement appartenant à l’historique de sélections comprenant un nombre de nœuds inférieur à un seuil donné. Procédé selon l’une quelconque des revendications 1 à 4 comprenant en outre une mise à jour de l’au moins un arbre obtenu, la mise à jour comprenant la suppression d’au moins un instant associé à un événement, l’au moins un instant supprimé étant antérieur à un premier instant, ou l’ajout d’au moins un instant associé à un événement, l’au moins un instant ajouté étant antérieur à un second instant postérieur au premier instant. Procédé selon l’une quelconque des revendications 1 à 5 comprenant en outre la sélection d’au moins une catégorie, les événements du sous-ensemble d’au moins un événement étant reliés à la au moins une catégorie sélectionnée par un chemin ne comprenant pas de nœud intermédiaire formé par une catégorie. Procédé selon la revendication 6 selon lequel la au moins une catégorie est sélectionnée selon la distribution des catégories des événements de l’historique de sélections. Procédé selon la revendication 7 selon lequel la au moins une catégorie est sélectionnée si la proportion des événements de l’historique de sélections liés à la au moins une catégorie est supérieure à un seuil donné. Procédé selon la revendication 7 ou la revendication 8 selon lequel la au moins une catégorie est sélectionnée de façon aléatoire si la proportion des événements de l’historique de sélections liés à la au moins une catégorie est inférieure à un seuil donné. Procédé selon l’une quelconque des revendications 6 à 9 selon lequel la au moins une catégorie est sélectionnée à partir de préférences d’un utilisateur déterminées à partir de l’historique de sélections d’événements. Procédé selon l’une quelconque des revendications 1 à 10 selon lequel une pluralité d’événements de l’ensemble d’événements appartient à au moins un groupe, des événements de l’au moins un arbre étant associés les uns aux autres par leur catégorie, leur au moins un groupe et leur au moins un élément selon des chemins comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie, au moins un groupe ou au moins un élément. Procédé selon la revendication 11 selon lequel une pluralité de groupes appartient à au moins une classe, les événements de l’au moins un arbre étant associés les uns aux autres par leur catégorie, leurs groupes, la au moins une classe et leur au moins un élément selon des chemins comprenant au moins un nœud formé d’au moins un événement, au moins une catégorie, au moins un groupe, au moins une classe ou au moins un élément. Procédé selon l’une quelconque des revendications 1 à 12 comprenant en outre une étape de filtrage du sous-ensemble d’au moins un événement. Programme d’ordinateur comprenant des instructions pour la mise en œuvre de chacune des étapes du procédé selon l’une des revendications 1 à 13, lorsque ce programme est exécuté par un processeur. Dispositif comprenant une unité de traitement configurée pour exécuter chacune des étapes du procédé selon l’une des revendications 1 à 13.