Brevet FR3131489A1 — publié le 20230630

Système de distribution de contenu Internet personnalisé Un système de distribution de contenu Internet personnalisé comprend un stockage(12) de pages web d’accueil, dans lequel chaque page web est associée d’une part à un identifiant de segment et d’autre part à une adresse de page web, certaines des pages web étant associées à la même adresse de page web de telle sorte que chacune de ces pages web définit une version personnalisée d’une page web générique associée à ladite même adresse de page web, un serveur web (4) agencé pour recevoir une requête générique d’accès à une page web, ladite requête étant émise depuis un dispositif (3) relié à Internet, comprenant une adresse de page web munie d’une empreinte dudit dispositif, pour déterminer un identifiant de segment associé à ladite empreinte, et pour accéder audit stockage (12) pour obtenir et renvoyer audit dispositif (3) une page web associée à ladite adresse de page web de la requête générique et audit identifiant de segment. Fig.1 Système de distribution de contenu Internet personnalisé L’invention concerne les serveurs web et plus particulièrement la fourniture de contenus personnalisés. Il est maintenant devenu classique de personnaliser les contenus des sites web en fonction des visiteurs. Cette personnalisation rend les contenus plus attrayants et améliore d’une manière générale l’expérience utilisateur. Actuellement, il existe deux familles de méthodes de personnalisation : - les méthodes à base d’identification préalable, et - les méthodes agnostiques. Dans le cas des méthodes à base d’identification, un visiteur possède un compte sur le serveur web qu’il visite, et le serveur web est donc en mesure d’offrir un contenu personnalisé pour l’utilisateur, puisqu’il sait de qui il s’agit. Ces méthodes à base d’identification préalable manquent de souplesse et de fluidité pour l’utilisateur. En effet, page web un utilisateur doit d’abord s’authentifier pour avoir un contenu personnalisé, ce qui nuit à son expérience en rajoutant une étape qui lui demande de surcroît de retenir ou stocker un identifiant et un mot de passe. La seconde famille de méthodes, à savoir celle des méthodes agnostiques utilise classiquement deux types de solutions. Le premier type de solution consiste à afficher une page web classique, puis à la personnaliser dès que possible. Cette personnalisation est en général réalisée soit par un rechargement automatique et non sollicité par l’utilisateur, dès qu’on a pu associer cet utilisateur à un cluster d’utilisateurs, soit par personnalisation de sous-ensembles de la page en utilisant un code JavaScript. Le rechargement de la page n’est pas compatible avec une expérience utilisateur (UX pour « User experience » en anglais) satisfaisante et il peut même être perçu comme un défaut du site. L’utilisation de JavaScript pose des problèmes de maintien à jour du code, ainsi que l’impossibilité de mise en œuvre dans les environnements sécurisés, l’exécution de JavaScript étant souvent bloquée. En outre, le fait que l’utilisateur voit la personnalisation se faire sous ses yeux peut lui faire prendre conscience de cette personnalisation, et peut lui donner l’impression que celle-ci est artificielle, voire destinée à le manipuler. Cela dégrade considérablement l’UX. L’invention vient améliorer la situation. À cet effet, elle propose un système de distribution de contenu Internet personnalisé comprenant un stockage(12) de pages web d’accueil, dans lequel chaque page web est associée d’une part à un identifiant de segment et d’autre part à une adresse de page web, certaines des pages web étant associées à la même adresse de page web de telle sorte que chacune de ces pages web définit une version personnalisée d’une page web générique associée à ladite même adresse de page web, un serveur web agencé pour recevoir une requête générique d’accès à une page web, ladite requête étant émise depuis un dispositif relié à Internet, comprenant une adresse de page web munie d’une empreinte dudit dispositif, pour déterminer un identifiant de segment associé à ladite empreinte, et pour accéder audit stockage pour obtenir et renvoyer audit dispositif une page web associée à ladite adresse de page web de la requête générique et audit identifiant de segment. Ce système est particulièrement avantageux car il permet, d’offrir une personnalisation dès le chargement de la page web. De plus, comme l’utilisateur accède à une page web déjà personnalisée, qui est donc plus pertinente, améliore son UX sans qu’il ne s’en rende compte. Selon divers modes de réalisation, l’invention peut présenter une ou plusieurs des caractéristiques suivantes : - le serveur web comprend un proxy inverse agencé pour requêter une base de données dans laquelle chaque empreinte est associée à un identifiant de segment, - le proxy inverse est un serveur NGINX, - le proxy inverse est un microservice, - le serveur web est agencé pour recevoir une requête d’accès à une page web émise par un utilisateur depuis un dispositif relié à Internet, dépourvue d’empreinte dudit dispositif, et pour générer ladite empreinte et la retourner avec une version généraliste de ladite page web, et - le serveur web est agencé pour recevoir une requête générique d’accès à une page web comprenant une adresse de page web munie d’un identifiant de segment et pour accéder directement pour accéder audit stockage avec cette requête générique d’accès. L’invention concerne également un procédé de distribution de contenu Internet personnalisé comprenant les opérations suivantes : a) recevoir une requête générique d’accès à une page web, ladite requête étant émise par un utilisateur depuis un dispositif relié à Internet, comprenant une adresse de page web munie d’une empreinte dudit dispositif, b) déterminer un identifiant de segment associé audit utilisateur à partir de ladite empreinte dudit dispositif, c) accéder à un stockage de pages web d’accueil, dans lequel chaque page web est associée d’une part à un identifiant de segment et d’autre part à une adresse de page web, certaines des pages web d’accueil étant associées à la même adresse de page web de telle sorte que chacune de ces pages web d’accueil définit une version personnalisée d’une page web générique associée à ladite même adresse de page web, et récupérer une page web associée à ladite adresse de page web de la requête générique et audit identifiant de segment déterminé à l’opération b), et d) renvoyer audit dispositif la page web récupérée à l’opération c). D’autres caractéristiques et avantages de l’invention apparaîtront mieux à la lecture de la description qui suit, tirée d’exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels : représente un diagramme générique d’un premier mode de réalisation d’un système de distribution de contenu Internet personnalisé. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. La représente un diagramme générique d’un système de distribution de contenu Internet personnalisé 2 selon l’invention. Le système de distribution de contenu Internet personnalisé 2 reçoit des requêtes d’accès à des contenus web, en particulier des pages web d’un ou plusieurs dispositifs 3 qui sont connectés à Internet. Dans l’exemple décrit ici, le système de distribution de contenu Internet personnalisé 2 comprend un ou plusieurs serveurs web 4 comprenant un proxy inverse 6 et un ou plusieurs serveurs 8, une base de données 10 associant des identifiants de requête Reqid et des identifiants de segment SN, et un stockage 12 qui contient des pages web d’accueil. Dans l’exemple décrit ici, le proxy inverse 6 et le ou les serveurs 8 peuvent être réalisés sous la forme d’un code informatique ou programme approprié exécuté sur un ou plusieurs processeurs. Par processeurs, il doit être compris tout processeur adapté aux calculs décrits plus bas. Un tel processeur peut être réalisé de toute manière connue, sous la forme d’un microprocesseur pour ordinateur personnel, d’une puce dédiée de type FPGA ou SoC, d’une ressource de calcul sur une grille ou dans le cloud, d’une grappe de processeurs graphiques (GPUs), d’un microcontrôleur, ou de toute autre forme propre à fournir la puissance de calcul nécessaire à la réalisation décrite plus bas. Un ou plusieurs de ces éléments peuvent également être réalisés sous la forme de circuits électroniques spécialisés tel un ASIC. Une combinaison de processeur et de circuits électroniques peut également être envisagée. Des processeurs dédiés à l’apprentissage automatique pourront aussi être envisagés. Le proxy inverse 6 et le ou les serveurs 8 seront décrits plus en détails plus bas et pourraient être réunis sous la forme d’une seule unité. En outre, ils comprennent des moyens de communication par Internet leur permettant de recevoir des requêtes de contenu Internet depuis un ou plusieurs des dispositifs 8, et pour retourner à ceux-ci ce contenu s’il leur est accessible. Dans l’exemple décrit ici, la base de données 10 et le stockage 12 peuvent être mis en œuvre sur tout type de stockage de données propre à recevoir des données numériques : disque dur, disque dur à mémoire flash, mémoire flash sous toute forme, mémoire vive, disque magnétique, stockage distribué localement ou dans le cloud, etc. Les données calculées par le système 2 peuvent être stockées sur tout type de mémoire similaire à la mémoire de la base de données 10 et du stockage 12, ou sur ceux-ci. Ces données peuvent être effacées après que le système 2 a effectué ses tâches ou conservées. Le serveur web 4 a pour fonction classique de recevoir des requêtes de contenu Internet du dispositif 8 et de retourner ce contenu à ce dernier. D’une manière classique selon le protocole http (ou https), cela est réalisé par l’émission d’une requête GET qui contient l’adresse web ou localisateur uniforme de ressource (URL pour « Uniform Resource Locator » en anglais) à laquelle un utilisateur du dispositif 8 cherche à accéder. Dans les serveurs web classique 4, il n’est pas possible de personnaliser une ressource Web sans que l’utilisateur soit authentifié, c’est-à-dire qu’il ait ouvert une session d’identification sous une quelconque forme auprès du serveur web. C’est cette authentification qui permet au serveur web de choisir des contenus personnalisés pour l’utilisateur à partir d’une même adresse de page web générique. Par contenu personnalisé, on entend par exemple le fait d’afficher une page sur laquelle tout ou une partie du contenu est modifié en fonction, par exemple, des envies et/ou goûts et/ou préférences et/ou habitudes et/ou localisation et/ou la langue de l’utilisateur authentifié. Par exemple, sur un site d’actualités sportives, cela peut être réalisé en mettant en valeur le contenu récent relatif à une ou plusieurs équipes qu’un utilisateur a indiqué préférer. Le système de distribution de contenu Internet personnalisé 2 selon l’invention est particulier en ce qu’il permet un traitement spécifique des requêtes de pages d’accueil en l’absence d’une authentification de l’utilisateur. Dit autrement, le système de distribution de contenu Internet personnalisé 2 reçoit une requête générique dépourvue d’identifiant de l’utilisateur, et est pourtant agencé pour fournir à cet utilisateur une version de la page web qui est adaptée à ses envies et/ou goûts et/ou préférences. Cela est d’autant plus remarquable que la page web est un cas particulier où le serveur web n’a accès à aucune information qui permette de personnaliser l’expérience utilisateur en l’absence d’authentification, alors que le serveur web peut essayer de mettre en œuvre une personnalisation pour les autres pages d’un site, par exemple sur la base du parcours ayant permis d’y accéder depuis la page web. Pour cela, la Demanderesse a découvert qu’il est avantageux de réaliser un pré-traitement de la requête d’accès à la page web, même si cela doit retarder de quelques millisecondes son chargement côté client, afin de fournir une page web pré-personnalisée. Ainsi, le serveur web 4 reçoit une requête d’accès à une page web Hp.html référencée GET(Hp.html) sur la , et la transmet directement à un proxy inverse 6. L’utilisation de proxys inverses 6 est en elle-même connue principalement afin de réaliser un équilibrage de charge (« Load balancing » en anglais) pour les serveurs web 4 comprenant un grand nombre de serveurs 8 permettant de gérer des flux de visiteurs importants. Dans le mode de réalisation décrit ici, le proxy inverse 6 est partiellement détourné de son usage premier afin de permettre de personnaliser la page web retournée au dispositif 3. Pour cela, le proxy inverse 6 utilise un identifiant Reqid du dispositif 3. Cet identifiant, lorsqu’il existe, est stocké localement dans un cookie sur le dispositif 3, et est transmis au serveur web 4 avec la requête GET(Hp.html). Dans le cas où le dispositif 3 ne contient pas d’identifiant Reqid, celui-ci est généré et stocké pour la prochaine visite. Dans l’exemple décrit ici, l’identifiant Reqid est généré par un paquet fingerprint.js (https://fingerprintjs.com), ce qui garantit d’obtenir un identifiant unique pour chaque dispositif 3. En variante, d’autres méthodes pourront être utilisées pour générer l’identifiant Reqid. A partir de l’identifiant Reqid, le proxy inverse 6 interroge la base de données 10 afin de récupérer un identifiant de segment. Les identifiants de segments sont utilisés pour choisir le contenu personnalisé. Plus précisément, les utilisateurs des dispositifs 3 sont regroupés en fonction de leur comportement. Par exemple, ils peuvent être regroupés parce qu’ils ont visité une page particulière précédemment, ou une succession de pages particulières, ou parce que leur attitude a été similaire (par exemple, mise dans un panier d’un article mais pas d’achat, sélection d’informations particulières, etc.), etc. Une fois ce regroupement déterminé, une page web personnalisée est définie pour ce groupe d’utilisateurs, également appelé segment. Enfin, le base de données 10 est mise à jour afin d’associer d’une part les identifiants Reqid et d’autre part les identifiants de segment qui leur correspond. Ainsi, lorsque le proxy inverse 6 accède à la base de données 10, il récupère un identifiant de segment Sn qui désigne un groupe d’utilisateurs pour lequel une personnalisation particulière a été prévue. Afin d’optimiser les performances, la base de données 10 peut avantageusement être mise en œuvre sur la forme d’un cache au sein du proxy inverse 6. En variante, elle peut être mise en œuvre de toute autre manière utile. Ensuite, le proxy inverse 6 utilise le couple page web - identifiant de segment pour obtenir la version personnalisée de la page web Hp.html pour le segment d’identifiant Sn dans le stockage 12. Dans l’exemple décrit ici, cela est réalisé en adjoignant un suffixe correspondant à l’identifiant de segment Sn au nom de la page web. D’autres réalisations seront possibles, comme un stockage dans des répertoires associés à l’identifiant de segment, d’autres conventions de nommage, etc. Dans l’exemple décrit ici, le proxy inverse 6 est un serveur NGINX. En variante, le proxy inverse 6 pourrait être un autre proxy inverse, comme un serveur HAProxy ou Traefik. Toujours en variante, le proxy inverse 6 pourrait être un microservice, par exemple mis en œuvre au moyen d’un serveur lambda de la société Amazon Web Services. En variante, le dispositif 3 peut stocker l’identifiant de segment Sn de la même manière qu’il stocke l’identifiant Reqid une fois que ce dernier a été déterminé. Ainsi, lorsque le serveur web 4 reçoit une requête d’accès à la page Hp.html, l’identifiant de segment Sn est transmis comme les autres cookies, et le serveur web 4 peut aller directement solliciter le stockage 12 avec l’URL de la page web Hp.html et l’identifiant de segment Sn afin de retourner la version personnalisée. Ainsi, le serveur 8 peut retourner au dispositif 3 la page Hp_Sn.html qui est la version personnalisée de la page Hp.html pour le segment d’identifiant de segment Sn associé au dispositif 3. En variante, le stockage 12 pourrait contenir non pas une copie entière de la page web personnalisée, mais seulement des éléments de personnalisation, le serveur 8 ayant alors la charge de les combiner avec la version générique de la page web avant de l’envoyer au dispositif 3. Le système de distribution de contenu Internet personnalisé 2 permet donc de fournir à l’utilisateur du dispositif 3 une version personnalisée de la page web d’un site, sans que l’utilisateur soit authentifié, et sans que celui-ci puisse se rendre compte qu’une personnalisation a été mise en œuvre entre sa requête et l’affichage sur son écran de la page web. Dans les tests mis en œuvre par la Demanderesse, celle-ci a pu vérifier que la mise en œuvre du système 2 ne nécessite que 10ms, ce qui rend ce temps d’exécution transparent pour l’utilisateur. Système de distribution de contenu Internet personnalisé comprenant un stockage(12) de pages web d’accueil, dans lequel chaque page web est associée d’une part à un identifiant de segment et d’autre part à une adresse de page web, certaines des pages web étant associées à la même adresse de page web de telle sorte que chacune de ces pages web définit une version personnalisée d’une page web générique associée à ladite même adresse de page web, un serveur web (4) agencé pour recevoir une requête générique d’accès à une page web, ladite requête étant émise depuis un dispositif (3) relié à Internet, comprenant une adresse de page web munie d’une empreinte dudit dispositif, pour déterminer un identifiant de segment associé à ladite empreinte, et pour accéder audit stockage (12) pour obtenir et renvoyer audit dispositif (3) une page web associée à ladite adresse de page web de la requête générique et audit identifiant de segment. Système de distribution de contenu Internet personnalisé selon la revendication 1, dans lequel le serveur web (4) comprend un proxy inverse (6) agencé pour requêter une base de données (10) dans laquelle chaque empreinte est associée à un identifiant de segment. Système de distribution de contenu Internet personnalisé selon la revendication 2, dans lequel le proxy inverse (6) est un serveur NGINX. Système de distribution de contenu Internet personnalisé selon la revendication 2, dans lequel le proxy inverse (6) est un microservice. Système selon l’une des revendications précédentes, dans lequel le serveur web (4) est agencé pour recevoir une requête d’accès à une page web émise par un utilisateur depuis un dispositif (3) relié à Internet, dépourvue d’empreinte dudit dispositif (3), et pour générer ladite empreinte et la retourner avec une version généraliste de ladite page web. Système selon l’une des revendications précédentes, dans lequel le serveur web (4) est agencé pour recevoir une requête générique d’accès à une page web comprenant une adresse de page web munie d’un identifiant de segment et pour accéder directement pour accéder audit stockage (12) avec cette requête générique d’accès. Procédé de distribution de contenu Internet personnalisé comprenant les opérations suivantes : a) recevoir une requête générique d’accès à une page web, ladite requête étant émise par un utilisateur depuis un dispositif relié à Internet, comprenant une adresse de page web munie d’une empreinte dudit dispositif, b) déterminer un identifiant de segment associé audit utilisateur à partir de ladite empreinte dudit dispositif, c) accéder à un stockage de pages web d’accueil, dans lequel chaque page web est associée d’une part à un identifiant de segment et d’autre part à une adresse de page web, certaines des pages web d’accueil étant associées à la même adresse de page web de telle sorte que chacune de ces pages web d’accueil définit une version personnalisée d’une page web générique associée à ladite même adresse de page web, et récupérer une page web associée à ladite adresse de page web de la requête générique et audit identifiant de segment déterminé à l’opération b), et d) renvoyer audit dispositif la page web récupérée à l’opération c).