Brevet FR3147018A1 — publié le 20240927

Dispositif et procédé de suivi d’un utilisateur accédant à un site web L’invention concerne un procédé et un système (PT1) de suivi d’un utilisateur (UR1) accédant à un site web (ST1). Le procédé comprend : réception, depuis un terminal client (T1), de données d’utilisateur (DT3) représentatives de l’utilisateur (UR1) accédant au site web via un client de navigation (12) ; obtention, à partir des données d’utilisateur (DT3), d’au moins une empreinte numérique (FP1) de l’utilisateur ; obtention de données de comportement (DT4) représentatives d’un comportement de l’utilisateur sur le site web (ST1) ; et enregistrement de données d’historique (DH1) de l’utilisateur à partir des données de comportement (DT4) en association avec ladite au moins une empreinte numérique (FP1) pour permettre un suivi du comportement de l’utilisateur sur le site web (ST1). Figure pour l’abrégé : Fig. 1. dispositif et procédé de suivi d’un utilisateur accédant à un site web L'invention se rapporte au domaine du suivi de site web et porte plus particulièrement sur le suivi du comportement d’un utilisateur accédant à un site web, et ce quelles que soient les ressources utilisées par le client pour consulter le site web. Arrière-plan technologique Il est primordial pour les propriétaires de sites web, notamment les sites marchands (ou e-commerçants), d’être capables de savoir quels visiteurs accèdent à leur site, comment ils y accèdent et ce qu’ils font au cours de leurs visites. De nombreux outils de suivi de site web (dit aussi outils de suivi d’audience ou de « web tracking ») ont été développés ces dernières années pour permettre un tel suivi. Le suivi de site web se réfère à des techniques variées de pistage d’internautes lors de leur navigation sur des sites web. Autrement dit, ces techniques visent à suivre l’évolution d’un client sur un site web. Une majorité de sites web utilise ainsi des outils d’audience, de type Google Analytics® ou Google Adsense®, qui permettent d’agréger des informations sur les utilisateurs d’un site, parmi lesquelles l’adresse IP des visiteurs (pour déterminer leur localisation géographique), le comportement des visiteurs (pour déterminer les liens sur lesquels ils cliquent, le temps passé sur chaque page ou encore les pages qui sont consultées) ou encore des informations concernant les visiteurs (centres d’intérêt, etc.). Le suivi de site web peut être mis en œuvre pour différentes raisons, notamment à des fins statistiques, marketing ou commerciales. Grâce à ces informations de suivi, les propriétaires de site web peuvent suivre les performances de leur site, analyser le comportement des clients, comprendre leurs centres d’intérêts et adapter en conséquence le contenu de leur site web, notamment les contenus publicitaires. Les sites marchands utilisent ainsi ce type d’outil afin de faire un profilage consommateur et d’encourager les conversions menant à la vente. En identifiant les pages web qui obtiennent les meilleurs résultats, le e-commerçants sont en mesure d’y diriger les visiteurs ou d’appliquer la même stratégie sur d’autres pages. Le suivi de site web fait appel à divers outils mais leurs capacités sont aujourd’hui limitées et ne permettent pas d’assurer un pistage satisfaisant des utilisateurs, en particulier lorsque ceux-ci utilisent des moyens de protection contrariant un tel suivi. En outre, les solutions de suivi actuelles ne respectent pas certaines règles de respect de confidentialité des données personnelles (telles que la réglementation générale de la protection des données, dite « RGPD », en Europe). Lorsqu’un utilisateur d’un site web s’authentifie (par exemple au moyen d’un identifiant client et mot de passe), le propriétaire du site peut aisément pister l’utilisateur et suivre son comportement. Cependant, un utilisateur peut consulter un site web sans s’authentifier, soit parce que le site ne nécessite pas d’authentification ou parce que l’utilisateur préfère visiter le site anonymement. Il est courant d’utiliser des mouchards ou traqueurs dissimulés sur les sites web visités. Ainsi, la technique des cookies (appelant aussi « témoins » ou « témoins de connexion ») est couramment utilisée pour pister les utilisateurs de site web. Un cookie est un fichier (généralement de petite taille) qui est stocké par un serveur dans le terminal d’un internaute lorsque ce dernier consulte un site web. Ce fichier est automatiquement renvoyé lors de consultations ultérieures du même site web. Ce fichier contient des informations d’identification (identifiant de panier, de session, ...). Certains types de cookies sont nécessaires aux fonctionnalités expressément demandées par l’utilisateur tandis que d’autres nécessitent généralement un consentement de l’utilisateur avant la consultation du site. Cependant, le recours aux cookies n’est pas toujours apprécié des utilisateurs qui ont parfois tendance à refuser leur usage. En outre, certains utilisateurs ont recours à des navigateurs web sécurisés qui empêchent le recours aux cookies afin d’assurer la confidentialité des utilisateurs lors de leur navigation. Par ailleurs, la multiplication des terminaux rend difficile le pistage des utilisateurs dans la mesure où un même utilisateur peut utiliser différents terminaux (tablette, ordinateur portable, smartphone, etc.) pour accéder plusieurs fois à un même site web. La qualité de suivi d’un utilisateur sur un site web varie donc grandement selon les situations, notamment en fonction des ressources utilisées par un utilisateur pour accéder à un site web ou selon le niveau de protection dont bénéficie l’utilisateur lors de ses accès. Il est donc aujourd’hui difficile, voire impossible, de suivre efficacement le comportement et les centres d’intérêt d’un utilisateur sur un site web au cours d’une ou plusieurs visites dans le temps. L’un des objets de la présente invention est de résoudre au moins l’un des problèmes ou déficiences de l’arrière-plan technologique décrit précédemment. En particulier, un objet de la présente invention vise à permettre un suivi performant d’un site web, et ce quel que soit les ressources utilisées (navigateurs, protections, terminal, etc.) par les utilisateurs pour accéder au site web. En particulier, un objet de la présente invention vise à pister efficacement un utilisateur lorsqu’il accède à un site web. A cet effet, un premier aspect de l’invention concerne un procédé de suivi d’un site web, mis en œuvre par un système de suivi, ledit procédé comprenant : a) réception, depuis un terminal client, de données d’utilisateur représentatives d’un utilisateur accédant au site web via un client de navigation ; b) obtention, à partir des données d’utilisateur, d’au moins une empreinte numérique de l’utilisateur ; c) obtention de données de comportement représentatives d’un comportement de l’utilisateur sur le site web ; et d) enregistrement de données d’historique de l’utilisateur à partir des données de comportement en association avec ladite au moins une empreinte numérique pour permettre un suivi du comportement de l’utilisateur sur le site web. Le procédé selon le premier aspect de l’invention peut comporter d’autres caractéristiques qui peuvent être prises séparément ou en combinaison, notamment parmi les modes de réalisation qui suivent. Selon un mode particulier de réalisation, le procédé comprend : - en réponse à une demande d’accès du client de navigation au site web, envoi d’un module d’identification causant l’exécution dudit module d’identification par le client de navigation, dans lequel les données d’utilisateur sont reçues depuis le module d’identification. Selon un mode particulier de réalisation, les données d’utilisateur comprennent au moins l’une quelconque parmi : - des données de système représentatives de propriétés de système du terminal client ; et - des données de navigateur représentatives de propriétés du client de navigation. Selon un mode particulier de réalisation, ladite au moins une empreinte numérique comprend au moins l’une quelconque parmi : - une première empreinte numérique, dite empreinte système, générées à partir des données de système ; et - une deuxième empreinte numérique, dite empreinte navigateur, générées à partir des données de navigateur. Selon un mode particulier de réalisation, le procédé comprend : - génération de données de profil par surveillance du comportement de l’utilisateur sur le site web, les données de profil étant représentatives d’une consultation d’au moins une page web ou objet web ; les données de comportement étant obtenues au moins à partir desdites données de profil. Selon un mode particulier de réalisation, la surveillance comprend : - détection que l’utilisateur accédant au site web a consulté une page web, ou un objet web ; - en réponse à ladite détection, mise à jour d’un compteur représentatif d’un temps de consultation, ou d’un nombre de consultations, d’au moins l’un parmi : ● ladite page web ou ledit objet web ; ● d’au moins une information constitutive de ladite page web ou dudit objet web. Selon un mode particulier de réalisation, les données de profil sont représentatives d’une consultation d’au moins une page web, ou objet web, défini par au moins un élément d’une taxonomie ; dans lequel le compteur mis à jour est représentatif d’un temps de consultation, ou d’un nombre de consultations, dudit au moins un élément de la taxonomie. Selon un mode particulier de réalisation, les données de comportement comprennent des données applicatives et un identifiant, associés à au moins une application exécutée par le terminal client, les données applicatives et l’identifiant étant enregistrés dans les données d’historique en association avec les données de comportement et ladite au moins une empreinte numérique. Selon un mode particulier de réalisation, l’enregistrement d) des données d’historique comprend un envoi, à une plateforme de gestion de relations clients, des données de comportement en association avec ladite au moins une empreinte numérique pour historisation en tant que données d’historique dans une base de données. Selon un mode particulier de réalisation, les étapes a) à d) sont réitérées pour chacune parmi une pluralité de visites de l’utilisateur sur le site web, dans lequel les données d’historique de l’utilisateur sont mises à jour à partir des données de comportement obtenues en association avec chaque empreinte numérique correspondant audit utilisateur. Selon un mode particulier de réalisation, le procédé comprend : - collecte de données de formulaire soumises par l’utilisateur accédant au site web ; et - enregistrement des données de formulaire dans les données d’historique en association avec ladite au moins une empreinte numérique et les données de comportement. Selon un mode particulier de réalisation, le procédé comprend : - obtention de données décodées par décodage d’un lien enrichi en données via lequel l’utilisateur accède au site web ; - enregistrement des données décodées dans les données d’historique en association avec ladite au moins une empreinte numérique. Dans un mode particulier de réalisation, les différentes étapes du procédé de suivi selon le premier aspect de l’invention sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, un second aspect de l’invention vise un programme d’ordinateur sur un support d’informations (ou support d’enregistrement), ce programme étant susceptible d’être mis en œuvre dans un dispositif de suivi ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de suivi selon le premier aspect de l’invention. Ainsi, le procédé du premier aspect de l’invention peut être implémenté au moyen d’une mémoire non volatile stockant des instructions de programmes d’ordinateur et au moyen d’un processeur exécutant ces instructions. Le programme d’ordinateur selon le deuxième aspect peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Un troisième aspect de l’invention vise un support d'informations (ou support d’enregistrement) lisible par un processeur ou par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon le deuxième aspect de l’invention. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire non volatile réinscriptible ou ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Un quatrième aspect de l’invention vise un dispositif de suivi (ou dispositif de pistage) configuré pour mettre en œuvre le procédé de suivi du premier aspect de l’invention. Selon un exemple, le quatrième aspect prévoit un dispositif de suivi comprenant une mémoire associée à au moins un processeur configuré pour la mise en œuvre des étapes du procédé de suivi selon le premier aspect de l’invention. Ainsi, selon un exemple particulier, le quatrième aspect de l’invention vise un dispositif de suivi d’un site web, comprenant : - un module de réception configuré pour recevoir, depuis un terminal client, des données d’utilisateur représentatives d’un utilisateur accédant au site web via un client de navigation ; - un premier module d’obtention configuré pour obtenir, à partir des données d’utilisateur, au moins une empreinte numérique de l’utilisateur ; - un deuxième module d’obtention configuré pour obtenir des données de comportement représentatives d’un comportement de l’utilisateur sur le site web ; et - un module d’historisation configuré pour mettre à jour de données d’historique de l’utilisateur à partir des données de comportement en association avec ladite au moins une empreinte numérique pour permettre un suivi du comportement de l’utilisateur sur le site web. A noter que les différents modes de réalisation définis ci-avant (ainsi que ceux décrits ci-après) en relation avec le procédé de suivi du premier aspect de l’invention ainsi que les avantages associés s’appliquent de façon analogue au dispositif de suivi du quatrième aspect de l’invention. Pour chaque étape du procédé de suivi, le dispositif de suivi de l’invention peut comprendre un module (ou une unité) correspondant configuré pour réaliser ladite étape. Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » (ou unité) peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Selon un exemple particulier, les modules définis dans ce document correspondent à des composants logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. Un tel composant logiciel peut être exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit dans ce document pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. La présente invention permet avantageusement de réaliser un suivi ciblé (ou personnalisé) et efficace au cours du temps du comportement d’un utilisateur sur un site web, et ce quelles que soient les ressources (terminal client, client de navigation, etc.) utilisées par l’utilisateur pour accéder au site web. Un tel suivi est rendu possible notamment en couplant les données de comportement à l’utilisateur dans les données d’historique. L’association des données de comportement à l’empreinte numérique permet de garantir que l’utilisateur est reconnu de façon fiable, le cas échéant à chaque visite de cet utilisateur sur le site web, et ce même si cet utilisateur utilise des moyens de protection pour anonymiser ses accès au site web (par exemple un client de navigation sans cookie) ou utilise des terminaux clients différents lors de plusieurs visites du site web. La présente invention permet notamment d’offrir un système de type CRM (gestion de la relation client) qui reconnaît (ou qualifie) les visiteurs d’un site web en utilisant leurs empreintes numériques comme identifiants, y compris les visiteurs inconnus qui ne sont pas identifiés auprès du site (par login/mot de passe, ou par cookie par exemple) et qui utilisent éventuellement des protections contre le pistage ou encore des terminaux différents au cours de leurs visites du site. Un même utilisateur peut ainsi être reconnu à chaque visite d’un site web sans que l’identité de cet utilisateur soit connue (pas d’obligation de collecter des données personnelles (nom, date de naissance, etc.) ou des cookies). Si un utilisateur utilisant deux terminaux différents pour accéder au même site web s’authentifie avec les deux terminaux (par exemple au moyen de formulaires), il est alors possible d’associer dans les données d’historique cet utilisateur avec les deux empreintes numériques générées pour les deux terminaux. On peut ainsi suivre l’évolution des données de comportement de l’utilisateur au cours du temps et en déduire des informations pertinentes sur le comportement de cet utilisateur sur le site, telles que le nombre visites du site, le parcours de l’utilisateur à chaque visite du site, les centres d’intérêt de l’utilisateur, ses habitudes de consommation, etc. L’invention permet de centraliser un ensemble d’informations pertinentes d’un utilisateur, en particulier les informations de comportement précitées. En assurant un suivi ciblé et fiable de l’utilisateur au cours du temps, le propriétaire du site web peut mieux comprendre le profil de l’utilisateur (besoins, centres d’intérêt, etc.), et ainsi adapter le contenu du site web en conséquence, par exemple en créant ou adaptant le contenu en fonction du profil de l’utilisateur (création d’offres ou de contenus publicitaires en adéquation avec les centres d’intérêt de l’utilisateur, etc.). On peut ainsi optimiser le fonctionnement d’un site web, quel que soit le domaine concerné ou le but recherché. Le système de l’invention permet par exemple d’optimiser les ventes d’un site marchand ou d’optimiser les recettes publicitaires d’un site quelconque. Dans un système de E-learning (apprentissage en ligne) par exemple, le système de l’invention permet de mieux suivre le comportement d’un utilisateur et donc de mieux comprendre les intérêts des apprenants. Dans une plateforme de partage de contenus multimédias, l’invention permet d’adapter les contenus multimédias proposés à un même utilisateur au fil du temps en fonction de ses préférences. D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 5 annexées, sur lesquelles : La représente schématiquement un environnement comprenant un terminal client et un dispositif de suivi, selon au moins un mode de réalisation de l’invention (configuration « client-side ») ; La représente schématiquement le dispositif de suivi de la , selon au moins un mode de réalisation de l’invention ; La représente, sous forme d'un diagramme, les étapes d’un procédé de suivi selon au moins un mode de réalisation de l’invention ; La représente, sous forme d'un diagramme, les étapes d’un procédé de suivi selon au moins un mode de réalisation de l’invention ; et La représente schématiquement un environnement comprenant un terminal client et un dispositif de suivi, selon au moins un mode de réalisation de l’invention (configuration « serveur-side »). Des exemples de mise en œuvre de l’invention vont à présent être décrits dans ce qui va suivre en référence conjointement aux figures 1-5. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc.) sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des dispositifs, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. Comme déjà indiqué, la présente invention vise notamment des dispositifs et procédés de suivi d’un site web. La présente invention s’applique à un quelconque site web (ou site), tel qu’un site Internet par exemple ou un site implémenté dans un autre réseau qu’Internet (site Intranet, etc.). L’invention vise notamment, mais pas exclusivement, le suivi d’un site marchand (ou site d’e-commerce). De façon connue, un site web (par exemple un site Internet) comprend au moins une page web accessible par une adresse web (par exemple une adresse URL pour « Uniform Resource Locator »). Chaque page web peut avoir un contenu variable accessible par un utilisateur via un client de navigation approprié. En particulier, une page web peut contenir un ou des objets web, tels que des images, du texte, des fichiers (par exemple de type PDF), des emails, etc. Un site web peut comprendre une pluralité de pages web reliées ensemble par des hyperliens au sein du site. La consultation d’un site web ou d’une page web s’appelle une visite (ou consultation). Un site web est hébergé par au moins un serveur web, appelé communément système de gestion de contenu (ou CMS pour « Content Management System »), ce serveur étant accessible via un réseau de communication approprié, tel qu’Internet, un réseau Intranet local ou n’importe quel autre réseau tel que le réseau Tor® par exemple. Un protocole client-serveur, par exemple de type HTTP (pour « Hyper Text Transfer Protocol »), est généralement utilisé pour gérer les communications entre un serveur web et un client. Pour accéder à un site web, le client utilise un client de navigation, à savoir un logiciel permettant de consulter et afficher des sites ou pages web. La présente invention s’applique à divers types de client de navigation, par exemple à un navigateur web, à une application (par exemple une application Android® ou IOS®), ou encore à un client de messagerie (par exemple de type Outlook® ou Thunderbird®) qui peut être relié à un réseau ou au web. Un client de messagerie permet par exemple de consulter des emails qui constituent des objets web lorsque ce client de messagerie est connecté à un réseau ou au web. L’invention concerne notamment un procédé de suivi (ou procédé de pistage), mis en œuvre par un dispositif de suivi (ou dispositif de pistage), pour réaliser le suivi d’un site web ou plus précisément le suivi du comportement d’un utilisateur sur un site web. Ce procédé repose en particulier sur l’obtention d’au moins une empreinte numérique représentative d’un utilisateur accédant au site web et sur la mise à jour (ou enregistrement) de données d’historique comprenant des données de comportement de l’utilisateur en association avec l’empreinte numérique. Cette empreinte numérique permet d’identifier et suivre le comportement d’un utilisateur lors d’une ou plusieurs visites distinctes du site web, et ce quelles que soient les ressources employées par l’utilisateur pour accéder au site web. Selon différents modes de réalisation, le procédé de suivi comprend : a) réception, depuis un terminal client, de données d’utilisateur représentatives d’un utilisateur accédant au site web via un client de navigation ; b) obtention, à partir des données d’utilisateur, d’au moins une empreinte numérique de l’utilisateur ; c) obtention de données de comportement représentatives d’un comportement de l’utilisateur sur le site web ; et d) mise à jour de données d’historique de l’utilisateur à partir des données de comportement en association avec ladite au moins une empreinte numérique pour permettre un suivi du comportement de l’utilisateur sur le site web. D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. La représente schématiquement un environnement comprenant un dispositif de suivi PT1 apte à coopérer avec un terminal client T1 d’un utilisateur UR1. Le dispositif PT1 et le terminal client T1 forment ensemble un système noté SY1 (configuration « client-side »). Plus spécifiquement, le dispositif de suivi PT1 est une plateforme, un système ou des moyens informatiques (comprenant par exemple un serveur) configurés pour gérer un site web noté ST1. Cette plateforme (logicielle et/ou matérielle) constitue dans cet exemple un système de gestion de contenu (CMS) du site web ST1. La plateforme PT1 est appelé par la suite « système » « ou système CMS » à titre purement illustratif. Le système PT1 gère les accès d’utilisateurs (ou clients), dont l’utilisateur UR1, au site web ST1. Comme déjà indiqué, le contenu et la nature de ce site web ST1 peut varier selon le cas. Le site web ST1 comprend au moins une page web 32 qui comprend elle-même du contenu, à savoir au moins un objet web 34. Le site web ST1 peut ainsi comprendre une pluralité de pages web 32 reliées entre elles par des hyperliens. Chaque page web 32 peut comprendre divers types d’objet web, tel que des images, du texte, des emails, des fichiers, des calques de données dites « data layers », etc. Une page web 32 ou un objet web peuvent correspondre par exemple à un produit ou article présenté par le propriétaire du site web ST1. Le site web ST1 est par exemple un site marchand (de type e-commerce) bien que l’invention s’applique plus généralement à un quelconque site web contenant un ou des objets web consultables par un client UR1 au moyen d’un client de navigation. Comme décrit par la suite dans des exemples particuliers, des identifiants notés respectivement ID1 et ID2 peuvent être attribués aux pages web 32 et objets web 34 ( ). Par ailleurs, les pages web 32 et/ou les objets web 34 peuvent être définis selon au moins une taxonomie 36 (par exemple une taxonomie de pages et/ou une taxonomie d’objets). En particulier, chaque page web 32 et objet web 34 peut être défini par (ou correspondre à) au moins un élément d’une taxonomie 36. Un élément de la taxonomie 36 peut être qualifié par exemple par une catégorie ou étiquette. A titre purement illustratif, une page web 32 peut appartenir (ou être défini) par au moins deux éléments de taxonomie 36 (ou l’un quelconque parmi ces deux éléments), à savoir un élément de catégorie (par exemple : catégorie « chemise », « Tee-shirt », etc.) et un élément d’étiquette (par exemple : « manche courte », « manche longue », « nouvelle saison », « saison dernière », etc.). La structure de la taxonomie 36 peut être adaptée au cas par cas. L’utilisateur UR1 utilise un client de navigation 12 implémenté dans un terminal client T1 pour accéder (ou visiter) le site web ST1. Grâce à ce client de navigation 12, l’utilisateur est capable de consulter une page web 32 ou un objet web 34 du site web ST1. Comme déjà indiqué, le type et la configuration du client de navigation 12 peuvent varier selon le cas, en fonction notamment de la configuration du terminal client T1 (système d’exploitation, paramétrages, etc.). Le client de navigation 12 permet de coopérer avec le système PT1 selon un système client-serveur pour accéder au site web ST1. A cet effet, le client de navigation 12 peut être par exemple un navigateur web, une application ou encore un client de messagerie. Le terminal client T1 utilisé par le client UR1 peut varier selon le cas. Il peut s’agir par exemple d’un PC, d’un ordinateur portable, d’une tablette, d’un smartphone ou d’un quelconque autre équipement informatique permettant de consulter le site internet ST1 mis à disposition par le système CMS PT1. Dans l’exemple considéré, le terminal T1 et le système PT1 communiquent ensemble au travers d’un réseau de communication noté NT1, ce réseau pouvant être par exemple le réseau Internet, un réseau intranet ou un quelconque autre réseau permettant la communication entre un terminal client et un serveur. Le client UR1 peut par exemple accéder au site web ST1 en activant (ou cliquant sur) un lien web configuré pour diriger le client vers le site web en question. En variante, le client UR1 peut être amené à visiter un autre site web ST2, dit site intermédiaire ou site transitoire (par exemple un site d’un réseau social ou autre), qui comprend un lien que l’utilisateur UR1 peut activer pour être redirigé vers le site web ST1. Comme illustré en , le système PT1 peut comprendre un processeur 20 et un module de contrôle PG3 (dit aussi unité de contrôle, agent de contrôle, ou module/unité/agent de suivi). Comme déjà indiqué, le module de contrôle PG3 peut être un composant logiciel et/ou matériel. Selon un exemple particulier, le module PG3 est un programme d’ordinateur exécuté par le processeur 20. A cet effet, le système PT1 peut comprendre une mémoire non volatile (non représentée) dans laquelle est stocké le module de contrôle PG3. La mémoire non volatile dans laquelle est stocké le module de contrôle PG3 constitue alors un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier de l’invention, ce support étant lisible par le système PT1 (et plus précisément par le processeur 20). Ce programme d’ordinateur PG3 peut ainsi comporter des instructions pour l’exécution des étapes d’un procédé de suivi de l’invention comme décrit ci-après dans des modes de réalisation particuliers. Selon un exemple particulier, le processeur 20 est donc configuré pour exécuter les instructions du programme d’ordinateur PG3 afin de réaliser des étapes du procédé de suivi. A cet effet, le processeur 20 peut utiliser une mémoire volatile de type RAM (non représentée) du système PT1, par exemple de la mémoire intégrée au processeur et/ou une mémoire externe au processeur, pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du système PT1, y compris pour exécuter le programme d’ordinateur PG3 lors de la mise en œuvre du procédé de suivi de l’invention. Comme décrit plus en détail ci-après, le système PT1 peut traiter et stocker des données dans au moins une mémoire non volatile (non représentée) du système PT1, en particulier des données DT4 et au moins une empreinte numérique FP1. Selon un exemple particulier, le système PT1 peut également traiter et stocker des données de formulaires FM1 soumises par l’utilisateur UR1 au cours d’une visite du site web ST1. La nature et l’utilisation de ces différentes données sont décrites ultérieurement dans des exemples particuliers de réalisation. Comme illustré en , le terminal client T1 peut comprendre un processeur 10, un module d’analyse PG1 et un module de contrôle (dit aussi unité de contrôle ou module/unité de suivi) PG2. De même que PG3, les modules PG1 et PG2 peuvent être des composants logiciels et/ou matériels. A noter que des exemples de réalisation sont possibles dans lesquels le module d’analyse PG1 n’est pas implémenté par le terminal T1. Selon un exemple particulier, le module PG2, et le cas échéant le module PG1, sont des programmes d’ordinateur exécutés par le processeur 10 au sein du client de navigation 12. Autrement dit, les modules PG2 et éventuellement PG1 font partie du (ou sont implémentés par le), et sont exécutés, par le client de navigation 12. A cet effet, le terminal client T1 peut comprendre une mémoire non volatile (non représentée) dans laquelle sont stockés les modules PG1 et PG2. La mémoire volatile réinscriptible dans laquelle est stockée le module de contrôle PG2 (et éventuellement aussi PG1) constitue alors un support d’enregistrement (ou support d’informations) conforme à un mode de réalisation particulier de l’invention, ce support étant lisible par le terminal client T1 (et plus précisément par le processeur 10). Le programme d’ordinateur PG2, et éventuellement PG1, peuvent ainsi comporter des instructions pour l’exécution des étapes d’un procédé de contrôle de l’invention comme décrit ci-après dans des modes de réalisation particuliers. A cet effet, le processeur 10 peut utiliser une mémoire volatile de type RAM (non représentée) du terminal T1, par exemple de la mémoire intégrée au processeur et/ou une mémoire externe au processeur, pour réaliser les différentes opérations et fonctions nécessaires au fonctionnement du terminal T1, y compris pour exécuter les programme d’ordinateur PG1 et PG2 lors de la mise en œuvre du procédé de contrôle de l’invention. Selon des exemples particuliers, le système PT1 est apte à coopérer avec une plateforme (ou dispositif) PT4. Cette plateforme PT4 est configurée pour stocker des données d’historique DH1 déterminées à partir de données DT4, transmises par le système PT1, comme décrit plus en détail ultérieurement. Selon des exemples particuliers, l’environnement peut en outre comprendre au moins l’une parmi des plateformes (ou dispositifs, ou systèmes) PT2 et PT3 comme décrit ci-après. La plateforme PT2 est une plateforme d’analyse de performance (par exemple de type Google Analytics® ou Matomo®, Piano Analytics®) mise en œuvre par au moins un serveur, cette plateforme (logicielle et/ou matérielle) étant configurée pour suivre ou analyser les performances d’un site web, à savoir le site ST1 dans les exemples considérés. Pour ce faire, la plateforme PT2 coopère avec le terminal client T1, au travers du réseau NT1 dans cet exemple, pour suivre les performances du site ST1 lorsque l’utilisateur UR1 accède au site ST1 via son client de navigation 12. Des exemples de réalisation de l’invention sans la plateforme PT2 sont toutefois possibles. Selon un exemple particulier, la plateforme PT3 est une plateforme (logicielle et/ou matérielle) configurée pour le traitement de données de formulaire, telles que les données FM1, susceptibles d’être soumises par l’utilisateur UR1 au cours d’une visite du site web ST1 via le client de navigation 12. La plateforme PT3 peut être mise en œuvre par au moins un serveur. Cette plateforme PT3 constitue par exemple un système de gestion de la relation client (GRC), dit aussi système CRM (pour « Custom Relationship Management »). Ce type de système permet de gérer des relations avec des contacts, par exemple des utilisateurs du site web ST1 dans cet exemple. Cette plateforme PT3 est par exemple apte à stocker, traiter et/ou échanger des données de contact relatives à des utilisateurs du site web ST1, ces données de contact étant déterminées à partir notamment des données de formulaire recueillies via un ou des formulaires implémentés sur le site web ST1. Des exemples de réalisation de l’invention sans la plateforme PT3 sont toutefois possibles. Comme représenté en selon un mode de réalisation particulier, le processeur 20 piloté par le programme d’ordinateur PG3 met ici en œuvre un certain nombre de modules, à savoir : un module de réception MD2, un premier module d’obtention MD4, un deuxième module d’obtention MD6 et un module d’historisation (ou de gestion d’historique) MD8. Plus spécifiquement, le module de réception MD2 est configuré pour recevoir, depuis le terminal client T1, des données d’utilisateur DT3 représentatives de l’utilisateur UR1 accédant au site web ST1 via le client de navigation 12. Le premier module d’obtention MD4 est configuré pour obtenir, à partir des données d’utilisateur DT3, au moins une empreinte numérique FP1 de l’utilisateur UR1. Le deuxième module d’obtention MD6 configuré pour obtenir des données de comportement DT4 représentatives d’un comportement de l’utilisateur UR1 sur le site web ST1. Le module d’historisation MD8 est configuré pour mettre à jour (ou enregistrer) des données d’historique DH1 de l’utilisateur UR1 à partir des données de comportement DT4 en association avec ladite au moins une empreinte numérique FP1 pour permettre un suivi du comportement de l’utilisateur UR1 sur le site web ST1. La configuration et le fonctionnement des modules MD2-MD8 implémentés par le système CMS PT1 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après en référence aux figures 3 et 4. Les modules MD2-MD8 tels que représentés en ne représentent qu’un exemple de mise en œuvre non limitatif de l’invention. Comme décrit par la suite dans des variantes de réalisation, les modules MD2-MD8 peuvent être implémentés en tout ou partie par une autre plateforme (ou autre système) que le système PT1, telle que par exemple dans le système PT4 ou dans le client de navigation 12 du terminal T1. Selon un exemple particulier, le module de réception MD2 est exécuté par le module de contrôle PG3 tandis que les modules MD4, MD6 et MD8 sont exécutés par un système différent (externe) de PT1 (par exemple par une autre plateforme ou un autre serveur, tel que PT4 par exemple). Dans ce cas, PG2 et/ou PG3 sont configurés pour collecter l’ensemble des données nécessaires pour les traitement réalisés par les modules MD4, MD6 et MD8. De manière générale, pour chaque étape du procédé de suivi mis en œuvre par le système PT1, le système PT1 peut comprendre un module correspondant configuré pour réaliser ladite étape. Le procédé de suivi de l’invention, mis en œuvre par le système PT1 (et plus particulièrement par le module de contrôle PG3) illustré en figures 1-2 , est à présent décrit ci-après dans des modes de réalisation particuliers conjointement aux figures 3-4 . La représente schématiquement des étapes réalisées par le système PT1, et plus précisément par le module de contrôle PG3, lors d’un procédé de suivi selon un exemple particulier de réalisation. Pour ce faire, le processeur 20 implémente par exemple le module de contrôle PG3. On suppose dans cet exemple que l’utilisateur UR1 utilise son terminal client T1 pour accéder au site web ST1 géré par le système CMS PT1. L’accès de l’utilisateur UR1 au site ST1 se fait via le client de navigation 12. Le client de navigation 12 gère les interactions entre l’utilisateur UR1 et le site web ST1. Il permet par exemple d’afficher une ou des pages web 32 du site web ST1 sur un écran d’affichage (non représenté) du terminal client T1. L’accès au site ST1 peut se faire de diverses manières. L’utilisateur UR1 peut par exemple entrer dans son client de navigation une adresse URL (ou un nom de domaine) du site web ST1. Selon un exemple, l’utilisateur UR1 active un hyperlien (ou lien web) pointant vers le site web ST1 (par exemple en cliquant sur ce lien). Cet hyperlien définit une adresse web (par exemple URL) du site web ST1. Ainsi, le navigateur web 12 utilise l’adresse définie par l’hyperlien pour demander au système PT1 l’accès au site web ST1. Selon un exemple, l’utilisateur UR1 accède au site web ST1 par l’intermédiaire d’un site intermédiaire ST2 (par exemple un réseau social ou autre), différent de ST1, sur lequel est fourni un hyperlien, par exemple un lien enrichi en données. En activant cet hyperlien, l’utilisateur est redirigé grâce à son client de navigation 12 vers le site web ST1. Au cours d’une étape S2 de réception ( ), le système PT1 reçoit, depuis le terminal client T1, des données d’utilisateur DT3 représentatives de l’utilisateur UR1 accédant au site web ST1 via son client de navigation 12. Les données d’utilisateur DT3 permettent au système PT1 de reconnaître (ou d’identifier) l’utilisateur UR1. Comme décrit par la suite, cette reconnaissance ne nécessite pas d’obtenir des données personnelles (nom, prénom, date de naissance, etc.) de l’utilisateur. Pour ce faire, on suppose dans cet exemple que le module de contrôle PG2 a au préalable collecté les données d’utilisateur DT3 au sein du client de navigation 12 et ces données sont ensuite transmises au système PT1. Comme déjà indiqué, un problème réside en ce qu’il peut être difficile de reconnaître ou identifier l’utilisateur UR1, en particulier si celui-ci utilise un terminal client T1 inconnu ou inhabituel, ou encore si son client de navigation implémente un mécanisme de sécurité (par exemple un bloqueur de publicité, navigateur web limitant les cookies tiers, etc.) limitant l’accès à des informations relatives à l’utilisateur. La collecte des données d’utilisateur DT3 et leur traitement ultérieur permet de reconnaître avec précision l’utilisateur UR1, quelles que soient les ressources qu’il utilise pour accéder au site web ST1. Dans les exemples considérés, c’est le module de contrôle PG2, exécuté par ou chargé dans le client de navigation 12, qui collecte et envoie les données d’utilisateur DT3 au système PT1 via le réseau NT1. Ce module de contrôle PG2 est fourni par le système PT1 ou par le module PG3, par exemple sur détection d’une demande d’accès du client de navigation 12 au site web ST1. Selon un exemple particulier, préalablement à l’étape S2 de réception, le système PT1 reçoit une demande d’accès du client de navigation 12 pour accéder au site web ST1. En réponse à cette demande d’accès, le système PT1 ou le module de contrôle PG3 déclenche l’envoi du module de contrôle PG2 (ou de données permettant l’installation du module de contrôle PG2) au terminal client T1, causant ainsi l’exécution de ce module PG2 par le client de navigation 12. Le terminal client T1 reçoit ainsi le module de contrôle PG2 puis l’exécute au sein du client de navigation 12, ce module de contrôle PG2 se chargeant ensuite d’envoyer les données d’utilisateur DT3 (et le cas échéant ID3) au système PT1 pour permettre la reconnaissance (ou identification) de l’utilisateur UR1. Les données d’utilisateur DT3 reçues (S2) par le système PT1 peuvent être ou comprendre de quelconques données auxquelles le client de navigation 12 donne accès. Ces données d’utilisateur DT3 peuvent comprendre par exemple un identifiant ID3 de cookie (par exemple un cookie provenant de Google Analytics®) comme illustré en et/ou des données de calque (ou « data layers » en anglais) implantées par d’autres applications (du type PG1 par exemple). Les données d’utilisateur DT3 comprennent par exemple des données de système DT3a, ou des données de navigateur DT3b, ou les deux ( ). On suppose à titre illustratif dans ce qui suit que les données d’utilisateur DT3 comprennent des données de système DT3a et des données de navigateur DT3b, bien que des variantes soient possibles. Les données de système DT3a sont représentatives de propriétés (ou caractéristiques techniques) système du terminal client T1. Ces données de système DT3a caractérisent par exemple le terminal client T1, notamment des ressources logicielles et/ou matérielles implémentés dans le terminal T1. Les données de système DT3a caractérisent par exemple au moins l’un parmi : le terminal client T1 (par exemple le type du terminal, la version du terminal, la marque, les extensions du terminal, son type de stockage, etc.), le processeur 10 du terminal (le type et/ou la version du processeur par exemple), le système d’exploitation implémenté par le processeur 10 (par exemple le type et/ou la version du système d’exploitation), l’écran d’affichage du terminal T1 (résolution et/ou taille de l’écran par exemple), son adresse IP, voire son adresse MAC, etc. Selon un exemple particulier, le client de navigation 12 est configuré pour collecter des données de système DT3a auprès du terminal T1, par exemple lors d’une phase d’installation du client de navigation 12 dans le terminal T1. Les données de navigateur DT3b sont représentatives de propriétés (ou caractéristiques techniques) du client de navigation 12. Ces données DT3b caractérisent par exemple un type du client de navigation 12, une version du client de navigation 12 (par exemple type/version d’un navigateur web), et/ou au moins une extension (ou plugin) du client de navigation 12. A titre purement illustratif, le type du navigateur web peut être "Win32" et sa version (identifiant de version « buildID ») "20181001000000". Le nombre et le type des données de navigateur DT3b peuvent varier au cas par cas. Selon un exemple particulier, le client de navigation 12 est configuré pour obtenir des données de navigateur DT3b. Pour ce faire, le client de navigation 12 peut demander au terminal T1 de telles données de navigateur DT3b (le système du terminal T1 peut être configuré pour fournir ou non les données DT3b demandées). Le recours à la fois aux données de système DT3a et données de navigateur DT3b permet de renforcer les capacités du système PT1 à reconnaître de façon unique l’utilisateur UR1 accédant au site web ST1. Le croisement de ces données permet de reconnaître l’utilisateur UR1 de façon fiable même si celui-ci modifie par exemple son client de navigation ou si le système d’exploitation du terminal T1 est mis à jour entre deux visites du site web ST1. Selon un exemple particulier, les données d’utilisateur DT3 comprennent au moins un identifiant ID3 (dit aussi identifiant applicatif) d’une application ou d’un service exécuté par le client de navigation 12 (par exemple un identifiant de cookie de l’application Google Analytics®) ( ). Un tel identifiant ID3 peut comprendre par exemple des données de cookie, c’est-à-dire des données contenues dans des cookies stockés dans le terminal client T1. Ces données de cookies peuvent être collectées par le client de navigation 12 et incluses dans les données d’utilisateur DT3 transmises au système PT1. Selon un exemple particulier, les données d’utilisateur DT3 comprennent des données applicatives DT4b, résultant de l’exécution d’au moins une application dans le terminal client T1, éventuellement en association avec DT3a et/ou DT3b, voire également ID3. Selon un exemple particulier, au cours de l’étape S2 de réception, le système PT1 reçoit depuis le terminal client T1, outre les données d’utilisateur DT3, des données applicatives DT4b. Ces données applicatives D4b comprennent des informations caractérisant (ou définissant) des interactions de l’utilisateur UR1 avec le site web ST1, par exemple la sélection d’une page web 32 ou d’un objet web 34. A titre d’exemple, les données applicatives DT4b peuvent comprendre des données de calque (dites « data layer ») qui sont incluses dans le site web ST1 et permettent de détecter des interactions d’utilisateur (ou évènements), telles qu’un défilement de page web, un click sur une page ou un objet web, etc. Le recours aux données applicatives DT4b permet avantageusement de réaliser un suivi précis, et donc de mieux comprendre le parcours d’un visiteur sur le site web ST1 et ses centres d’intérêt, tels que des pages web et objets web consultés. Ces données applicatives DT4b peuvent par exemple permettre de déterminer comment l’utilisateur UR1 accède au site web ST1 (par exemple via une étiquette UTM pour « Urchin Tracking Module », c’est-à-dire une adresse URL enrichie en données). Selon un exemple particulier, le module d’analyse PG1 génère au sein du client de navigation 12 des données d’identification DT1 (comprenant par exemple un identifiant applicatif ID3 comme déjà décrit) et/ou des données de performance DT2 tandis que l’utilisateur UR1 accède au site web ST1. Ces données sont alors le résultat de l’exécution du module PG1. Le module PG1 peut par exemple générer des données de cookie comprenant un identifiant ID3 qui résulte de l’exécution de PG1. En variante, le module d’analyse (Tags Management, exemple google Tag management) PG1 peut contenir de telles données dans le code du système PT1. Le module d’analyse PG1 peut être configuré pour transmettre les données DT1 et/ou DT2 (éventuellement avec ID3) au système PT2. Les données d’identification DT1 peuvent comprendre par exemple des données caractérisant le client de navigation 12, des données de géolocalisation du terminal client T1, l’adresse IP du terminal client T1, etc. Les données de performance DT2 caractérisent des interactions de l’utilisateur UR1 via le client de navigation 12 avec des pages web 32 et/ou objets web 34 du site web ST1, par exemple le temps passé sur une page web 32, le nombre de consultations d’une page web 32, les objets web 34 sur lesquels l’utilisateur UR1 a cliqué ou qu’il a consultés, le parcours du pointeur (de la souris) sur un page web 32 affiché par le terminal client T1 (fonction de « mouse tracking »), et plus généralement toutes informations permettant d’analyser les performances du site web ST1. Comme indiqué ci-après dans un exemple particulier, l’identifiant ID3 peut notamment permettre d’établir une liaison entre les systèmes PT2 et PT4 de façon à pouvoir enrichir les données de PT4 avec les données de PT2. Des modes de réalisation ne mettant pas en œuvre les données DT1 et DT2 sont toutefois possibles. Au cours d’une étape S4 d’obtention ( ), le système PT1 obtient ou détermine à partir des données d’utilisateur DT3 au moins une empreinte numérique FP1 de l’utilisateur. Ce ou ces empreintes numériques FP1 (dites aussi « empreintes digitales » ou « empreintes », ou encore « fingerprint » en anglais) constituent un ou des identifiants de l’utilisateur UR1, de préférence des identifiants uniques. Selon un exemple, le système PT1 génère en S4 la ou les empreintes numériques FP1 à partir des données d’utilisateur DT3. Plus la quantité de données d’utilisateur DT3 utilisée est importante, et plus les empreintes numériques FP1 sont fiables et permettent donc d’identifier l’utilisateur UR1 avec un haut niveau de précision. La prise en compte des données de système DT3a et des données de navigateur D3b (voire éventuellement aussi de l’identifiant ID3) pour générer les empreintes FP1 permet en particulier d’améliorer le niveau de fiabilité de l’identification. Selon une variante, les données d’utilisateur DT3 fournies par le module de contrôle PG2 comprennent la ou les empreintes numériques FP1. Le module de contrôle PG3 récupère alors la ou les empreintes numériques FP1 dans les données d’utilisateur DT3 reçues (S4). Dans ce cas, le module de contrôle PG2 se charge par exemple de générer la ou les empreintes numériques FP1 à partir de tout ou partie des données d’utilisateur DT3. La ou les empreintes FP1 sont alors transmises avec les données d’utilisateur DT3 (voire aussi DT4b et/ou ID3) au système PT1. Chaque empreinte numérique FP1 peut être générée par exécution d’une fonction de hashage appropriée prenant en entrée les données d’utilisateur DT3. La fonction de hashage utilisée peut varier selon le cas d’usage. Une fonction de hashage est typiquement une fonction qui, pour un ensemble de grande taille (théoriquement infini) et de nature diversifiée en entrée, renvoie une sortie selon un format spécifique, à savoir un format prédéfini pour être traité comme décrit par la suite. Une empreinte numérique FP1 se présente par exemple sous la forme d’une chaîne unique de caractères identifiant l’utilisateur UR1 (par exemple, la fonction de hashage « md5 »). On suppose à titre d’exemple que le système PT1 obtient ou génère (S4) deux empreintes numériques, à savoir : une première empreinte numérique FP1a (ou premier sous-empreinte), dite empreinte système, générées à partir des données de système DT3a ; et une deuxième empreinte numérique FP1b (ou deuxième sous-empreinte), dite empreinte navigateur, générées à partir des données de navigateur DT3b ( ). L’empreinte système FP1a identifie ainsi l’utilisateur UR1 à partir des propriétés du système du terminal client T1. L’empreinte navigateur FP1b identifie ainsi l’utilisateur UR1 à partir des propriétés du client de navigation 12. L’usage combiné de l’empreinte système FP1a et de l’empreinte navigateur FP1b permet avantageusement de reconnaître (ou identifier) de façon plus fiable et robuste l’utilisateur UR1. En particulier, il est possible de reconnaître l’utilisateur UR1 alors que le système du terminal client T1 et/ou le client de navigation ont subi des modifications au cours du temps (mises à jour, changements de configuration, modifications logicielles et/ou matérielles, etc.). Si par exemple le client de navigation 12 est mis à jour entre deux consultations du site web ST1, il est malgré tout possible d’identifier l’utilisateur UR1 à partir de l’empreinte système FP1a ou par croisement des empreintes FP1a et FP1b. A titre purement illustratif, une fonction de hashage MD5 peut être appliquée sur chaque donnée de système DT3a (FP1a = md5(DT3a)) et sur chaque donnée de navigateur DT3b (FP1b = md5(DT3b)), produisant ainsi deux sous empreintes FP1a et FP1b. Une empreinte numérique FP1 est alors générée à partir de FP1a et FP1b, par exemple par hashage de FP1a et FP1b (FP1 = md5(FP1a “.” FP1b) ). A noter toutefois que des variantes sont possibles dans lesquelles le système PT1 obtient en S4 ( ) une seule de ces empreintes numérique, c’est-à-dire soit l’empreinte système FP1a, soit l’empreinte navigateur FP1b. Selon un exemple, au moins une empreinte numérique FP1 est obtenue ou générée à partir des données applicatives DT4b précitées. Selon un exemple particulier, le système PT1 obtient ou génère (S4), à partir des données d’utilisateur DT3, une empreinte numérique globale FP1 combinant l’empreinte système FP1a et l’empreinte navigateur FP1b telles que précédemment décrites. Pour ce faire, le système PT1 obtient ou génère par exemple l’empreinte système FP1a et l’empreinte navigateur FP1b à partir des données d’utilisateur DT3 (comme précédemment décrit) puis détermine l’empreinte numérique globale FP1 par concaténation des empreintes FP1a et FP1b. L’usage d’une seule empreinte numérique globale combinant FP1a et FP1b permet avantageusement de limiter la complexité des traitements de l’empreinte et facilite en particulier l’étape S8 d’historisation à venir. On suppose par la suite à titre d’exemple que le système PT1 génère en S4 une empreinte numérique globale FP1 à partir d’une empreinte système FP1a et d’une empreinte navigateur FP1b comme précédemment décrit. Au cours d’une étape S6 d’obtention ( ), le système PT1 obtient ou détermine des données de comportement DT4 représentatives d’un comportement (ou d’interactions) de l’utilisateur UR1 sur le site web ST1. Autrement dit, les données de comportement DT4 définissent comment l’utilisateur UR1 interagit avec les pages web 32 et/ou les objets web 34 au cours de la visite du site web ST1. Les données de comportement DT4 peuvent définir en particulier au moins une page web 32 et/ou au moins un objet web 34 consultés par l’utilisateur UR1 dans le site web ST1, ou encore des informations déterminées à partir des pages web 32 et/ou objets web 34 consultés. Selon un exemple particulier, lorsque l’utilisateur UR1 accède au site web ST1, le module de contrôle PG3 génère en S6 des données de profil DT4a ( ) par surveillance du comportement (ou des interactions) de l’utilisateur UR1 sur le site web ST1. Autrement dit, sur détection d’un accès de l’utilisateur UR1 au site web ST1, le module PG3 réalise une surveillance du comportement (ou des interactions) de l’utilisateur UR1 par rapport au contenu du site web ST1. Les données de profil DT4a ainsi générées sont représentatives d’une consultation d’au moins une page web 32 ou objet web 34 selon au moins un élément de la taxonomie 36. Les données de comportement DT4 générées en S6 ( ) sont alors obtenues au moins à partir de (ou comprennent) ces données de profil. Comme déjà décrit, l’élément de taxonomie 36 précité définit par exemple une catégorie et/ou une étiquette (tag ou caractéristique) selon lesquels sont organisés les pages web 32 et/ou objets web 34 du site ST1. Chaque page web 32 et/ou objet web 34 du site ST1 peuvent ainsi être associés à un élément de taxonomie tel que défini par la taxonomie 36. Selon un exemple particulier, au cours de la surveillance précitée (S6), le module de contrôle PG3 détecte que l’utilisateur UR1 (ou son client de navigation 12) a consulté, au cours de sa visite du site web ST1, une page web 32 et/ou un objet web 34, conforme à un élément de la taxonomie 36 (par exemple une catégorie et/ou une étiquette). Selon la taxonomie 36, chaque élément de taxonomie est associé à un identifiant, c’est-à-dire un couple (identifiant de taxonomie, valeur). Ainsi, en réponse à cette détection, le module de contrôle PG3 récupère (ou détermine) l’identifiant de l’élément de taxonomie 36 correspondant à la page web 32 et/ou un objet web 34 consulté, et met à jour (ou enregistre) un compteur CT1 représentatif d’un temps de consultation, ou d’un nombre de consultations, de l’élément de taxonomie consulté ( ), c’est-à-dire de l’élément de taxonomie correspondant à l’identification de taxonomie récupéré. Ainsi, selon un exemple, le compteur CT1 mis à jour représente (ou définit) un temps cumulé pendant lequel l’utilisateur UR1 a consulté sur le site web ST1 du contenu (page web(s) 32 et/ou objet(s) web 34) conforme à l’élément de taxonomie correspondant à l’identifiant récupéré. Selon un exemple, le compteur CT1 mis à jour représente (ou définit) un nombre cumulé de consultations par l’utilisateur UR1 sur le site web ST1 de contenus (page web(s) 32 et/ou objet(s) web 34) conformes à l’élément de taxonomie correspondant à l’identifiant récupéré. Selon un exemple, deux compteurs tels que précités sont mis à jour pour suivre respectivement le temps de consultation et le nombre de consultation d’un élément de taxonomie. Les données de profil DT4a générées (S6) par le module de contrôle PG3 peuvent alors comprendre le compteur CT1 mis à jour. Grâce à cette fonction de comptage (ou « scoring »), les données de comportement DT4 (comprenant les données de profil DT4a et donc le compteur CT1) peuvent être avantageusement utilisées pour suivre précisément l’évolution du comportement de l’utilisateur UR1 au cours du temps relativement à un type de page web ou d’objet web. On peut par exemple suivre dans le temps le niveau d’intérêt que porte l’utilisateur UR1 vis-à-vis d’un type de produit ou d’article particulier (par exemple la catégorie « chaussure » ou « chemise »), et ainsi collecter des informations pertinentes sur le profil de l’utilisateur, ses centres d’intérêt, ses habitudes de consommation, etc. Selon un exemple particulier, la mise à jour du compteur CT1 comprend une opération de cumul d’un tel compteur CT1 représentant le temps passé par l’utilisateur UR1 à consulter un type de taxonomie (c’est-à-dire un élément de taxonomie) tel que défini par la taxonomie 36. Autrement dit, le compteur CT1 cumule le temps de consultation par l’utilisateur UR1 d’un type de taxonomie donné, ou de contenu conforme audit type de taxonomie. Selon un exemple particulier, la mise à jour du compteur CT1 comprend une opération d’incrémentation d’un tel compteur CT1 représentant le nombre de visites (ou consultations) par l’utilisateur UR1 d’un type de taxonomie tel que défini par la taxonomie 36. Autrement dit, le module de contrôle PG3 peut incrémenter le compteur CT1 à chaque accès d’un même type de taxonomie (c’est-à-dire à chaque accès d’un contenu sur le site web ST1 conforme audit type de taxonomie) au cours du temps. Selon un exemple particulier, les pages web 32 et/ou les objets web 34 sont associés à des identifiants notés respectivement ID1 et ID2. Au cours de la surveillance réalisée en S6 ( ), le module de contrôle PG3 peut déterminer les identifiants ID1 des pages web 32 consultées par l’utilisateur UR1 et/ou les identifiants ID2 des objets web 34 consultés par l’utilisateur UR1. Le module de contrôle PG3 peut intégrer dans les données de profil DT4a au moins un identifiant de page ID1 et/ou au moins un identifiant d’objet ID2 ainsi déterminés au cours de la surveillance. Ces identifiants ID1 et ID2 peuvent correspondre par exemple à des numéros de page, références de produit, caractéristiques de produit, etc. Au cours d’une étape S8 ( ) d’enregistrement (ou de mise à jour, ou d’historisation), le module de contrôle PG3 met à jour (ou enregistre) des données d’historique DH1 de l’utilisateur UR1 à partir des données de comportement DT4 en association avec ladite au moins une empreinte numérique FP1 obtenue en S4, à savoir dans cet exemple une empreinte globale FP1 combinant les empreintes numériques FP1a et FP1b. Autrement dit, les données de comportement PT4 sont enregistrées en association avec l’empreinte numérique FP1 en tant que données d’historique DH1. La mise à jour (ou l’enregistrement) S8 des données d’historique DH1 peut être mise en œuvre de diverses manières selon le cas d’usage. Cette mise à jour S8 peut consister de manière générale à enregistrer les données de comportement DT4 en association avec l’empreinte numérique FP1 de l’utilisateur UR1. Les données d’historique DH1 qui sont mises à jour peuvent être stockées dans une quelconque mémoire non volatile accessible par le système PT1. A titre d’exemple, on considère par la suite que le module de contrôle PG3 déclenche (S8) l’enregistrement, en tant que données d’historique DH1, des données de comportement DT4 en association avec l’empreinte numérique FP1 dans la plateforme PT4. Cette plateforme PT4 peut comprendre par exemple une base de données (non représentée) configurée pour stocker les données d’historique DH1 mises à jour par le module de contrôle PG3. La plateforme PT4 est par exemple un système de type CRM (gestion de la relation client) configuré pour stocker et gérer les données de comportement DT4 de l’utilisateur UR1. Selon un exemple particulier, au cours de la mise à jour S8, le module de contrôle PG3 déclenche l’envoi, vers la plateforme CRM PT4, des données de comportement PT4 en association avec l’empreinte numérique FP1 pour historisation (enregistrement) en tant que données d’historique DH1, par exemple dans une base de données de la plateforme PT4. A noter que la mise à jour S8 de l’historique DH1 est aussi possible sans avoir recours à un outil CRM tel que la plateforme PT4. Toutefois, le couplage du système CMS PT1 avec la plateforme CRM PT4 permet d’offrir un suivi ciblé particulièrement performant d’un utilisateur UR1. Selon un exemple particulier, lors de la mise à jour S8 ( ), des anciennes données d’historique notées DH0 ( ) sont déjà stockées dans la plateforme PT4 en association avec l’empreinte numérique FP1 de l’utilisateur UR1 – ou une autre empreinte numérique FP0 de l’utilisateur UR1 (par exemple une empreinte proche de FP1) –, par exemple suite à une ou des précédentes visites par l’utilisateur UR1 du site ST1. Dans ce cas, la mise à jour S8 revient à enregistrer les données de comportement DT4 obtenues en S4 en tant que données d’historique DH1 en complément des anciennes données d’historique DH0 (par exemple par ajout, remplacement, etc.), en association avec l’empreinte numérique FP1 dans la plateforme PT4. Selon un exemple particulier, au moment de la mise à jour S8 ( ), aucune ancienne donnée d’historique DH0 n’est déjà stockée dans la plateforme PT4 en association avec une empreinte numérique de l’utilisateur UR1. Dans ce cas, la mise à jour S8 revient à enregistrer les données de comportement DT4 en tant que données d’historique DH1 en association avec l’empreinte numérique FP1 dans la plateforme PT4. L’enregistrement ou mise à jour d’historique S8 (dit aussi historisation) permet avantageusement de réaliser un suivi ciblé (ou personnalisé) et efficace au cours du temps du comportement de l’utilisateur UR1 sur le site web ST1, et ce quelles que soient les ressources (terminal client, client de navigation, etc.) utilisées par l’utilisateur UR1 pour accéder au site web ST1. Un tel suivi est rendu possible notamment en couplant les données de comportement DT4 à l’utilisateur UR1 dans les données d’historique DH1. L’association des données de comportement DT4 à l’empreinte numérique FP1 permet de garantir que l’utilisateur UR1 est reconnu de façon fiable, le cas échéant à chaque visite de cet utilisateur sur le site web ST1, et ce même si cet utilisateur utilise des moyens de protection pour anonymiser ses accès au site web ST1 (par exemple un client de navigation sans cookie) ou utilise des terminaux clients différents lors de plusieurs visites du site web ST1. La présente invention permet notamment d’offrir un système de type CRM (gestion de la relation client) qui reconnaît (ou qualifie) les visiteurs d’un site web en utilisant leurs empreintes numériques comme identifiants, y compris les visiteurs inconnus qui ne sont pas identifiés auprès du site (par login/mot de passe, ou par cookie par exemple) et qui utilisent éventuellement des protections contre le pistage ou encore des terminaux différents au cours de leurs visites du site. Un même utilisateur peut ainsi être reconnu à chaque visite d’un site web sans que l’identité de cet utilisateur soit connue (pas d’obligation de collecter des données personnelles (nom, date de naissance, etc.) ou des cookies). Si un utilisateur utilisant deux terminaux différents pour accéder au même site web ST1 s’authentifie avec les deux terminaux (par exemple au moyen de formulaires), il est alors possible d’associer dans les données d’historique DH1 cet utilisateur avec les deux empreintes numériques générées pour les deux terminaux. On peut ainsi suivre l’évolution des données de comportement DT4 de l’utilisateur UR1 au cours du temps et en déduire des informations pertinentes sur le comportement de cet utilisateur UR1 sur le site ST1, telles que le nombre visites du site, le parcours de l’utilisateur UR1 à chaque visite du site, les centres d’intérêt de l’utilisateur, ses habitudes de consommation, etc. L’invention permet de centraliser un ensemble d’informations pertinentes d’un utilisateur, en particulier les informations de comportement DT4 précitées. En assurant un suivi ciblé et fiable de l’utilisateur UR1 au cours du temps, le propriétaire du site web ST1 peut mieux comprendre le profil de l’utilisateur UR1 (besoins, centres d’intérêt, etc.), et ainsi adapter le contenu du site web ST1 en conséquence, par exemple en créant ou adaptant le contenu en fonction du profil de l’utilisateur UR1 (création d’offres ou de contenus publicitaires en adéquation avec les centres d’intérêt de l’utilisateur, etc.). On peut ainsi optimiser le fonctionnement d’un site web, quel que soit le domaine concerné ou le but recherché. Le système de l’invention permet par exemple d’optimiser les ventes d’un site marchand ou d’optimiser les recettes publicitaires d’un site quelconque. Dans un système de E-learning (apprentissage en ligne) par exemple, le système de l’invention permet de mieux suivre le comportement d’un utilisateur et donc de mieux comprendre les intérêts des apprenants. Dans une plateforme de partage de contenus multimédias, l’invention permet d’adapter les contenus multimédias proposés à un même utilisateur au fil du temps en fonction de ses préférences. Selon un exemple particulier, le procédé comprend en outre une étape de contrôle du site web ST1 (après l’étape S8 d’enregistrement) au cours de laquelle le système PT1 adapte le site web ST1 (par exemple son contenu) en fonction des données d’historique DH1 enregistrées en S8 pour l’utilisateur UR1. Pour ce faire, lors d’une consultation du site web ST1 par l’utilisateur UR1, le système UR1 peut récupérer (ou consulter) les données d’historique DH1 associées à l’utilisateur UR1 et adapter le contenu du site web ST1 en fonction des données d’historique DH1 ainsi récupérées. On peut ainsi avantageusement personnaliser certains éléments du site web ST1 selon le profil ou les centres d’intérêt de l’utilisateur UR1 et donc améliorer l’expérience utilisateur (adaptation des objets web présentés, adaptation d’un contenu publicitaire, etc.). Comme décrit ci-après dans différents exemples, il est en outre possible d’enrichir les données d’historique DH1 de l’utilisateur UR1 afin d’améliorer encore son suivi au cours du temps. Ainsi, comme déjà indiqué dans un exemple particulier, le module d’analyse PG1 du terminal client T1 peut générer au sein du client de navigation 12 des données d’identification DT1 et/ou des données de performance DT2 tandis que l’utilisateur UR1 accède au site web ST1. Comme illustré en , le module d’analyse PG1 peut alors transmettre les données DT1 et/ou DT2 à la plateforme PT2 d’analyse de performance (par exemple de type Google Analytics® ou Matomo®). A partir des données DT1 et/ou DT2, la plateforme PT2 suit ou analyse les performances du site web ST1. Selon un exemple, en réponse à l’accès de l’utilisateur UR1 au site web ST1, le module PG1 génère un cookie comprenant un identifiant applicatif ID3 comme déjà décrit. Le module PG1 transmet les données d’identification DT1 (comprenant l’identifiant ID3) et des données de performance DT2 au système PT2. Le système PT2 enregistre alors les données DT1 et DT2 en association avec ID3. En parallèle, le système PT1 enregistre (ou cause l’enregistrement) également au cours de la mise à jour S8 (figues 1-3) cet identifiant applicatif ID3 en association avec l’empreinte FP1 de l’utilisateur UR1 en tant que données d’historique DH1. L’enregistrement de l’identifiant ID3 dans les données d’historique DH1 permet avantageusement d’établir un lien (ou jointure) entre les données d’historique DH1 stockées dans le système PT4 d’une part et les données DT1 et DT2 stockées dans le système PT2 d’autre part. Grâce à cette liaison, il est possible d’enrichir les données d’historique DH1 avec les données d’autres applications. Cela permet d’améliorer encore le suivi de l’utilisateur UR1 en enrichissant ses données d’historique DH1 avec des données d’analyse de performances qui caractérisent les interactions de l’utilisateur UR1 (temps passé sur chaque page web 34, parcours du pointeur, etc.) avec le site web ST1. Par ailleurs, comme déjà indiqué, les données d’utilisateur DT3 obtenues en S2 (figures 1-3) peuvent comprendre des données applicatives DT4b (par exemple des données de calque). Selon un exemple particulier, ces données applicatives DT4b peuvent alors être incluses dans les données de comportement DT4 qui sont enregistrés (S8 ; ) dans les données d’historique DH1 en association avec l’empreinte numérique FP1. Par ailleurs, comme déjà indiqué, des données de formulaire FM1 peuvent être soumises par l’utilisateur UR1 au cours de son accès au site web ST1. De façon bien connue, un formulaire comprend un ensemble d’un ou plusieurs champs destinés à recevoir (ou contenir) des données saisies par un utilisateur. Typiquement, un utilisateur peut saisir des données dans un tel champ puis valider la saisie au moyen d’une commande appropriée. De telles données de formulaire FM1 peuvent être récupérées et traitées par le système PT1 ( ). Ces données de formulaire FM1 peuvent par exemple comprendre au moins l’une parmi les informations suivantes : nom du formulaire, nom de l’utilisateur, email de l’utilisateur, etc. Selon un exemple particulier, le système PT1 collecte les données de formulaire FM1 soumises par l’utilisateur et enregistre (S8 ; ) ces données de formulaire FM1 dans les données d’historique DH1 en association avec ladite au moins une empreinte numérique FP1 et les données de comportement DT4. L’ajout des données de formulaire FM1 dans les données d’historique DH1 en association avec l’empreinte FP1 permet avantageusement de créer un lien (ou jointure) entre d’une part les données d’historique DH1 de l’utilisateur UR1 et d’autre part les données de l’utilisateur UR1 contenues dans le système PT3. Cela permet d’améliorer encore le suivi de l’utilisateur UR1 en enrichissant ses données d’historique DH1 avec des données de formulaire. Ainsi, lorsqu’un utilisateur UR1 remplit un formulaire, on peut associer les données de formulaires collectées avec des données d’historique DH1 préexistantes qui ont été préalablement enregistrées (S8, ) comme décrit ci-avant. De façon avantageuse, il n’est pas nécessaire d’attendre qu’un utilisateur s’enregistre au moyen d’un formulaire pour commencer à suivre et analyser son comportement. De cette manière, on peut améliorer significativement le suivi du parcours d’un client, y compris lorsque celui-ci accède dans un premier temps au site web ST1 de façon anonyme. Par ailleurs, comme déjà indiqué, l’utilisateur UR1 peut accéder au site web ST1 de diverses manières, par exemple via un lien, enrichi en données, qu’il active depuis un site intermédiaire ST2 ( ). Selon un exemple particulier, le système PT1 obtient des données applicatives DT4b décodées par décodage d’un lien enrichi en données via lequel l’utilisateur UR1 accède au site web ST1. Autrement dit, le système PT1 décode ce lien enrichi activé par l’utilisateur UR1 pour accéder au site web ST1, ce décodage produisant des données décodées. Ces données décodées peuvent par exemple comprendre des données UTM. Au cours de l’étape S8 de mise à jour (figures 1-3), le système PT1 enregistre alors ces données décodées dans les données d’historique DH1 en association avec les données de comportement DT4 et l’empreinte numérique FP1. Cette fonction permet d’améliorer encore le suivi de l’utilisateur UR1 en enrichissant ses données d’historique DH1 avec des données décodées à partir d’un lien enrichi utilisé par l’utilisateur UR1 pour accéder au site web ST1. Cela permet avantageusement de déterminer l’origine et le contexte de l’arrivée de l’utilisateur UR1 sur le site web ST1. Par ailleurs, les étapes S2-S8 du procédé de suivi peuvent être réitérées une pluralité de fois au cours du temps, par exemple à chacune parmi une pluralité de visites du site web ST1 par l’utilisateur UR1. Ainsi, selon un exemple particulier, les étapes S2 à S8 ( ) sont réitérées pour chacune parmi une pluralité de visites de l’utilisateur UR1 sur le site web ST1. Les données d’historique DH1 de l’utilisateur UR1 sont alors mises à jour (S8) à partir des données de comportement DT4 obtenues en association avec chaque empreinte numérique FP1 correspondant audit utilisateur UR1. Comme déjà indiqué, un suivi fiable et personnalisé de l’utilisateur UR1 peut ainsi être réalisé au fil du temps, notamment au cours de plusieurs visites du site web ST1. Les empreintes numériques sont utilisées pour reconnaître un même utilisateur UR1 au cours de plusieurs visites du site web ST1 au cours du temps et pour rattacher à ce même utilisateur UR1 les données de comportement DT4 obtenues à chaque visite. La représente schématiquement des étapes réalisées par le système PT1, et plus précisément par le module de contrôle PG3, lors de plusieurs itérations (ou cycles) successives du procédé de suivi selon un exemple particulier de réalisation. Pour ce faire, le processeur 20 implémente par exemple le module de contrôle PG3. Les différents modes de réalisation des étapes S2-S8 du procédé de suivi décrit précédemment en référence aux figues 1-3 s’appliquent de façon analogue aux modes de réalisation décrits ci-après en référence à la . Dans cet exemple, on suppose que l’utilisateur UR1 réalise deux visites successives du site web ST1, par exemple au cours de deux jours différents (ou deux dates différentes). L’utilisateur UR1 peut utiliser par exemple son client de navigation 12 implémenté par le même terminal client T1, ce dernier ayant éventuellement subi des modifications matérielles et/ou logicielles entre les deux visites. Le système PT1 exécute ( ) une itération (ou un cycle) du procédé de suivi précédemment décrit pour chaque visite (ou consultation) du site web ST1, à savoir une première itération IT1 des étapes S2-S8 lors de la première visite et une deuxième itération IT2 des étapes S2-S8 lors de la deuxième visite (subséquent à la première visite). On suppose à titre d’exemple qu’avant la première visite (itération IT1) du site web ST1, l’utilisateur UR1 n’avait jamais visité ce site web, bien que des variantes soient possibles où l’utilisateur UR1 avaient déjà visité le site web. Ainsi, en réponse à la première visite par l’utilisateur UR1 du site web ST1, le système PT1 réalise la première itération IT1 ( ) des étapes S2 à S8 comme précédemment décrit en référence aux figures 1-3. Au cours de l’étape S4 d’obtention, l’empreinte numérique de l’utilisateur UR1 obtenue (ou générée) par le système PT1 est notée FP0 (figures 1 et 4). Au cours de l’étape S6 d’obtention, les données de comportement de l’utilisateur UR1 obtenues par le système PT1 sont notées DT0 (figures 1 et 4). Au cours de l’étape S8 de mise à jour, le système PT1 met ainsi à jour (ou enregistre) les données d’historique – notées DH0 – à partir des données de comportement DT0 en association avec l’empreinte numérique FP0 de l’utilisateur UR1 (figures 1 et 4). Il s’agit à ce stade de la première visite de l’utilisateur UR1 de sorte qu’aucune donnée d’historique n’était préalablement stockée en tant que donnée d’historique en association avec l’utilisateur UR1. Aussi, au cours de la mise à jour S8 de la première itération IT1, le système PT1 enregistre, en tant que données d’historique DH0 (figures 1 et 4), les données de comportement DT0 en association avec l’empreinte numérique FP0. Pour ce faire, le système PT1 envoie par exemple les données de comportement DT0 et l’empreinte numérique FP0 au système CRM PT4 pour enregistrement en tant que données d’historique DH0. Ultérieurement, en réponse à la deuxième visite par l’utilisateur UR1 du site web ST1, le système PT1 réalise la deuxième itération IT2 ( ) des étapes S2 à S8 comme précédemment décrit en référence aux figures 1-3. Au cours de l’étape S4 d’obtention, l’empreinte numérique de l’utilisateur UR1 obtenue (ou générée) par le système PT1 est notée FP1 (figures 1 et 4). Au cours de l’étape S6 d’obtention, les données de comportement de l’utilisateur UR1 obtenues par le système PT1 sont notées DT1 (figures 1 et 4). Au cours de l’étape S8 de mise à jour, le système PT1 met ainsi à jour les données d’historique – notées DH1 – à partir des données de comportement DT1 en association avec l’empreinte numérique FP1 de l’utilisateur UR1 (figures 1 et 4). Selon un exemple particulier, le système PT1 peut causer l’enregistrement (S8, figures 3-4), dans les données d’historique DH1 de l’utilisateur UR1, d’une pluralité d’empreintes numérique FP1 en association avec un même identifiant applicatif ID3. Ces empreintes FP1 sont obtenues (S4) selon le procédé de l’invention en réponse à une pluralité d’accès de l’utilisateur UR1 au site web ST1. Selon un exemple particulier, le système PT1 peut causer l’enregistrement (S8, figures 3-4), dans les données d’historique DH1 de l’utilisateur UR1, d’une pluralité d’empreintes numérique FP1 en association avec un même identifiant de données de formulaire. Cet identifiant de données de formulaire peut être un quelconque identifiant contenu dans des données de formulaire FM1 soumises par l’utilisateur UR1 lors de plusieurs soumissions de formulaire auprès du site web ST1. Cet identifiant peut par exemple être ou comprendre une adresse email de l’utilisateur UR1. Grâce à l’identifiant ID3 et/ou de l’identifiant de données de formulaire (adresse email), on peut avantageusement identifier l’ensemble des empreintes FP1 générées au cours du temps pour un même utilisateur UR1, pour un voire plusieurs terminaux T1. Selon un exemple particulier, au cours de l’étape de mise à jour S8 de la deuxième itération IT2, le système PT1 compare l’empreinte numérique FP1 générée en S4 (itération IT2) avec l’empreinte numérique FP0 – dite empreinte numérique de référence – préalablement enregistrée (S8, itération IT1) dans les données d’historique DH0 – dites données d’historique de référence – d’un utilisateur de référence ( ). Si l’empreinte numérique FP1 coïncide (ou concorde) avec ladite au moins une empreinte numérique de référence, le système PT1 détecte que l’utilisateur UR1 accédant au site web ST1 au cours de la deuxième itération IT2 est l’utilisateur de référence, à savoir celui pour lequel les données de comportement DT0 ont été préalablement enregistrées dans les données d’historique DH0. Dans ce cas, les données d’historique DH1 mises à jour en S8 (itération IT2) sont alors les données d’historique de référence DH0 en association avec l’empreinte numérique de référence FP0. Autrement dit, le système PT1 met à jour les données d’historique DH0 à partir des données de comportement DT1 en association avec l’empreinte numérique FP1. Le système PT1 complète par exemple les données d’historique DH0 en y incorporant (ou ajoutant) les données de comportement DT1. Ainsi, sur détection d’une nouvelle visite du site web ST1, le système PT1 obtient une nouvelle empreinte FP1, vérifie si cette nouvelle empreinte FP1 correspond à une empreinte de référence FP0 déjà historisée et, si oui, associe l’utilisateur UR1 réalisant la nouvelle visite aux données d’historique DH0 de l’empreinte de référence FP0, ce qui permet un suivi personnalisé dans le temps du comportement de l’utilisateur UR1 sur le site web ST1. Selon un exemple, les empreintes numériques FP0 et FP1, obtenues respectivement au cours des étapes d’obtention S4 des itérations IT1 et IT2, sont identiques. Dans ce cas, le système PT1 détecte que l’utilisateur accédant au site web ST1 lors des deux visites considérées est le même, à savoir UR1 dans cet exemple. Le système PT1 peut alors mettre à jour (S8) les données d’historique DH0 comme précédemment décrit. Selon un exemple, les empreintes numériques FP0 et FP1, obtenues respectivement au cours des étapes d’obtention S4 des itérations IT1 et IT2, sont différentes. Dans ce cas, au cours de l’étape S8 de mise à jour de la deuxième itération IT2 ( ), le système PT1 évalue un degré de similitude entre les empreintes numériques FP0 et FP1 pour déterminer si elles correspondent au même utilisateur UR1. Cette évaluation peut comprendre une comparaison des différents caractères de la chaîne des deux empreintes FP0 et FP1. Si les deux empreintes numériques FP0 et FP1 sont suffisamment proches, c’est-à-dire si le degré de similitude ainsi obtenu est au moins égal à une valeur seuil, alors ces empreintes sont traitées comme coïncidant l’une avec l’autre (autrement comme correspondant au même utilisateur UR1). Le système PT1 peut alors mettre à jour (S8) les données d’historique DH0 comme précédemment décrit. Si en revanche les deux empreintes FP0 et FP1 ne sont pas suffisamment proches, elles sont traitées comme correspondant à deux utilisateurs différents (autrement dit, l’utilisateur UR1 est différent de l’utilisateur de référence). Dans ce cas, les données de comportement DT4 de l’utilisateur UR1 sont enregistrées (S8) en tant que données d’historique DH1 en association avec l’empreinte numérique FP1, et ce indépendamment des données d’historique DH0 de l’utilisateur de référence. Dans les exemples de réalisation ci-avant, le procédé de l’invention est mis en œuvre par le système PT1 coopérant notamment avec le terminal client T1 et le système PT4. Comme déjà indiqué, des variantes sont toutefois possibles dans lesquelles le procédé est réalisé par une autre dispositif ou système. Certaines variantes de réalisation sont décrites ci-après à titre purement illustratif. La (configuration serveur) représente une variante de réalisation de l’environnement de la . L’environnement de la diffère principalement de celui de la en ce que les modules PG1 et PG2 ne sont pas exécutés par le terminal client T1 mais de façon déportée par un système (ou serveur, ou plateforme) PT0. Dans ce cas, le client de navigation 12 du terminal T1 reçoit depuis le système PT1, et exécute, un module de contrôle PG0. Ce module PG0 collecte toutes les données collectées par PG1 et PG2 dans les modes de réalisation précédemment décrit en référence à la . Le module PG0 distribue ces données au système PT0 qui lui-même distribue les données aux modules PG1 et PG2. Les modules PG1 et PG2 assurent par ailleurs les mêmes fonctions que celles précédemment décrites en référence à la . Autrement dit, dans cet exemple particulier, c’est également le système PT1 qui met en œuvre les étapes S2-S8 du procédé de l’invention comme précédemment décrit. Comme le comprend l’homme du métier, tous les modes de réalisation et variantes décrits ci-avant dont certains ont été simplifiés à dessein pour faciliter les explications, ne constituent que des exemples non limitatifs de mise en œuvre de la présente divulgation. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant, afin de répondre à un besoin particulier. La présente invention ne se limite donc pas aux exemples de réalisation décrits ci-avant mais s’étend notamment à un procédé de suivi qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif de suivi (ou système) pour la mise en œuvre d’un tel procédé. Procédé de suivi d’un site web, mis en œuvre par un système de suivi (PT1), ledit procédé comprenant : a) réception (S2), depuis un terminal client, de données d’utilisateur (DT3) représentatives d’un utilisateur (UR1) accédant au site web via un client de navigation (1) ; b) obtention (S4), à partir des données d’utilisateur (DT3), d’au moins une empreinte numérique (FP1) de l’utilisateur ; c) obtention (S6) de données de comportement (DT4) représentatives d’un comportement de l’utilisateur sur le site web ; et d) enregistrement (S8) de données d’historique (DH1) de l’utilisateur à partir des données de comportement (DT4) en association avec ladite au moins une empreinte numérique (FP1) pour permettre un suivi du comportement de l’utilisateur sur le site web. Procédé selon la revendication 1, dans lequel le procédé comprend : - en réponse à une demande d’accès du client de navigation au site web, envoi d’un module d’identification (PG2) causant l’exécution dudit module d’identification par le client de navigation, dans lequel les données d’utilisateur (DT3) sont reçues depuis le module d’identification. Procédé selon la revendication 1 ou 2, dans lequel les données d’utilisateur (DT3) comprennent au moins l’une quelconque parmi : - des données de système (DT3a) représentatives de propriétés de système du terminal client (T1) ; et - des données de navigateur (DT3b) représentatives de propriétés du client de navigation (NW1). Procédé selon la revendication 3, dans lequel ladite au moins une empreinte numérique comprend au moins l’une quelconque parmi : - une première empreinte numérique (FP1a), dite empreinte système, générées à partir des données de système ; et - une deuxième empreinte numérique (FP1b), dite empreinte navigateur, générées à partir des données de navigateur. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend : - génération de données de profil (DT4a) par surveillance du comportement de l’utilisateur sur le site web, les données de profil étant représentatives d’une consultation d’au moins une page web ou objet web ; les données de comportement étant obtenues au moins à partir desdites données de profil. Procédé selon la revendication 5, dans lequel la surveillance comprend : - détection que l’utilisateur accédant au site web a consulté une page web, ou un objet web ; - en réponse à ladite détection, mise à jour d’un compteur représentatif d’un temps de consultation, ou d’un nombre de consultations, d’au moins l’un parmi : ● ladite page web ou ledit objet web ; ● d’au moins une information constitutive de ladite page web ou dudit objet web. Procédé selon la revendication 6, dans lequel les données de profil sont représentatives d’une consultation d’au moins une page web, ou objet web, défini par au moins un élément d’une taxonomie ; dans lequel le compteur mis à jour est représentatif d’un temps de consultation, ou d’un nombre de consultations, dudit au moins un élément de la taxonomie. Procédé selon l’une quelconque des revendications précédentes, dans lequel les données de comportement (DT4) comprennent des données applicatives (DT4b) et un identifiant (ID3), associés à au moins une application exécutée par le terminal client, les données applicatives et l’identifiant étant enregistrés dans les données d’historique (DH1) en association avec les données de comportement (DT4) et ladite au moins une empreinte numérique (FP1). Procédé selon l’une quelconque des revendications précédentes, dans lequel l’enregistrement d) des données d’historique comprend un envoi, à une plateforme de gestion de relations clients (PT4), des données de comportement (DT4) en association avec ladite au moins une empreinte numérique pour historisation en tant que données d’historique dans une base de données. Procédé selon l’une quelconque des revendications précédentes, dans lequel les étapes a) à d) sont réitérées pour chacune parmi une pluralité de visites de l’utilisateur sur le site web, dans lequel les données d’historique de l’utilisateur sont mises à jour à partir des données de comportement (DT4) obtenues en association avec chaque empreinte numérique correspondant audit utilisateur. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend : - collecte de données de formulaire soumises par l’utilisateur accédant au site web ; et - enregistrement des données de formulaire dans les données d’historique (DH1) en association avec ladite au moins une empreinte numérique (FP1) et les données de comportement (DT4). Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend : - obtention de données (DT4b) décodées par décodage d’un lien enrichi en données via lequel l’utilisateur accède au site web ; - enregistrement des données décodées dans les données d’historique (DH1) en association avec ladite au moins une empreinte numérique (FP1). Programme d’ordinateur (PG3) comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur. Dispositif de suivi (PT1) d’un site web, comprenant : - un module de réception (MD2) configuré pour recevoir, depuis un terminal client, des données d’utilisateur (DT3) représentatives d’un utilisateur (UR1) accédant au site web via un client de navigation ; - un premier module d’obtention configuré pour obtenir, à partir des données d’utilisateur (DT3), au moins une empreinte numérique (FP1) de l’utilisateur ; - un deuxième module d’obtention configuré pour obtenir des données de comportement (DT4) représentatives d’un comportement de l’utilisateur sur le site web ; et - un module d’historisation configuré pour mettre à jour de données d’historique (DH1) de l’utilisateur à partir des données de comportement (DT4) en association avec ladite au moins une empreinte numérique (FP1) pour permettre un suivi du comportement de l’utilisateur sur le site web.