Brevet FR2980606A1 — publié le 20130329

L'invention concerne un procédé de brouillage d'un profil d'un utilisateur élaboré par un service à partir de requêtes que ledit utilisateur envoie audit service, ainsi qu'une application et une architecture comprenant des moyens pour mettre en oeuvre un tel procédé. L'accès à Internet est de plus en plus facile, notamment avec l'usage de plus en plus répandu de terminaux fournissant une connexion à Internet, tels que les smartphones, les ordinateurs de bureau, les ordinateurs portables ou encore les tablettes électroniques. Dans un tel contexte, la protection de la vie privée des utilisateurs de tels terminaux apparaît cruciale. En effet, les utilisateurs ne sont en général pas conscients du fait que, lorsqu'ils naviguent sur Internet, notamment pour faire des recherches, des informations relatives à leur vie privée et notamment à leurs centres d'intérêt peuvent être recueillies à leur insu, par exemple par des services de fourniture de moteurs de recherche tels que Google® ou par des services de fourniture d'accès à Internet, lesdits services utilisant alors lesdites informations pour envoyer auxdits utilisateurs des messages électroniques généralement indésirables pour lesdits utilisateurs (pour l'anglais spam), notamment des messages électroniques à caractère commercial. Pour recueillir de telles informations, ces services comprennent généralement des moyens pour analyser l'historique de connexion et/ou d'utilisation d'Internet d'un utilisateur, notamment les témoins de connexion (pour l'anglais cookies) stockés dans ledit historique ou les traces d'actions spécifiques menées par ledit utilisateur sur des sites Internet, comme par exemple le fait de marquer ses centres d'intérêts en activant avec sa souris un bouton « J'aime » sur une page d'un site Internet partenaire du site communautaire Facebook®, comme expliqué dans l'article disponible à l'adresse http://www.zdnet.fr/blogs/media- tech/bouton-like-j-aime-et-plugins-sociaux-facebook-obtient-le-nom-de-chaq ue- utilisateur-visitant-les-pages-equipees-demo-concrete-39751334.html. En particulier, ces services peuvent analyser les requêtes envoyées par les utilisateurs et les éléments contenus dans lesdites requêtes, par exemple les mots utilisés par lesdits utilisateurs dans lesdites requêtes. En outre, ces services comprennent des moyens pour établir un profil pour chaque utilisateur à partir de l'analyse des requêtes envoyées et des informations recueillies par ledit utilisateur, afin d'obtenir des données relatives aux centres d'intérêt dudit utilisateur, ledit profil étant ensuite utilisé par lesdits services, notamment à des fins commerciales. Ces services ne demandant pas le consentement de leurs utilisateurs avant d'élaborer leurs profils, la protection de la vie privée desdits utilisateurs n'est donc pas assurée. De plus, pour beaucoup d'utilisateurs, il n'est généralement pas agréable de savoir que toutes les actions qu'ils mènent en naviguant sur Internet sont analysées. Pour éviter ce désagrément, on connaît de l'art antérieur des procédés qui prévoient d'obscurcir les requêtes formulées par les utilisateurs. Par exemple, le logiciel TrackMeNot® permet, lorsqu'un utilisateur envoie une requête à un service de moteur de recherche, d'élaborer automatiquement des requêtes aléatoires, notamment sur des sujets d'actualité, et d'envoyer audit service lesdites requêtes avec la requête initiale dudit utilisateur, afin que ledit service élabore un profil brouillé pour l'utilisateur. Cependant, ce logiciel ne donne pas entière satisfaction. En effet, si utilisateur est intéressé par un sujet donné et envoie très souvent des requêtes sur ledit sujet, un service de moteur de recherche n'aura aucun mal à identifier, parmi les sujets des requêtes aléatoires émises par un tel logiciel, le sujet initial de l'utilisateur, puisque ce sujet a alors de fortes chances d'apparaître un très grand nombre de fois dans l'historique. En outre, le document US-2010/0169294 décrit un procédé dans lequel de fausses requêtes sont construites à partir de mots associés aux mots utilisés dans la requête initiale de l'utilisateur. En particulier, ce procédé prévoit d'utiliser les suggestions d'association de mots fournies par les services de moteurs de recherche, notamment les suggestions les plus populaires et/ou commerciales. Cependant, ce procédé ne donne pas non plus entière satisfaction, en ce qu'il prévoit de n'utiliser que des mots appartenant aux mêmes champs lexicaux que les mots de la requête initiale, et ne prend donc pas en compte les homonymes. Le document « Providing Privacy through Plausibly Deniable Search » (M. MURUGESAN, C. CLIFTON, 2009) propose un procédé utilisant une cartographie sémantique basée sur l'indexation sémantique latente pour générer un ensemble fixe de requêtes possibles, dites requêtes de couverture, ledit procédé étant en particulier agencé pour éviter que le service recevant les requêtes n'identifie facilement la requête initiale de l'utilisateur parmi les requêtes de couverture. Pour ce faire, le procédé génère les requêtes de couverture de sorte que chaque requête, initiale ou de couverture, présente la même probabilité et que chacune desdites requêtes présente un sujet différent. Cependant, ce procédé présente des inconvénients. En effet, il ne considère pas l'ensemble de l'historique de recherche de l'utilisateur, et ne se base que sur les requêtes récentes pour tenter de générer des requêtes de couverture, lesdites requêtes de couverture étant en outre similaires aux requêtes de couvertures récemment générées par ledit procédé. En outre, ce procédé ne prend pas en compte la popularité des requêtes qu'il génère et suppose que la liste des sujets permettant de générer des requêtes de couverture est toujours disponible, alors que lesdits sujets peuvent ne pas être réalistes. L'invention vise à perfectionner l'art antérieur en proposant notamment un procédé permettant de brouiller l'analyse faite par un service afin de protéger la vie privée d'un utilisateur, ledit procédé reposant sur une analyse plus complète de l'historique de recherche dudit utilisateur afin d'assurer un brouillage plus efficace. A cet effet, selon un premier aspect, l'invention propose un procédé de brouillage du profil d'un utilisateur élaboré par un service à partir de requêtes que ledit utilisateur envoie audit service, ledit procédé prévoyant, lorsque ledit utilisateur envoie une requête, d'analyser les éléments de ladite requête pour sélectionner les éléments les plus pertinents, de rassembler des éléments liés auxdits éléments sélectionnés, de générer au moins une requête additionnelle à partir desdits éléments rassemblés et de transmettre ladite requête additionnelle avec la requête audit service afin que le profil soit brouillé par lesdites requêtes, ledit procédé prévoyant en outre d'utiliser les requêtes transmises audit service pour élaborer au moins un profil brouillé et de valider en fonction dudit profil brouillé les requêtes additionnelles générées ultérieurement avant leur transmission audit service. Selon un deuxième aspect, l'invention propose une application comprenant des moyens pour recevoir une requête envoyée par un utilisateur, ladite application comprenant en outre : - un module d'analyse des éléments de la requête, ledit module comprenant des moyens pour sélectionner les éléments les plus pertinents à partir de ladite analyse ; - un module de rassemblement d'éléments liés auxdits éléments sélectionnés ; - un module de génération d'au moins une requête additionnelle à partir desdits éléments rassemblés ; - des moyens pour transmettre ladite requête additionnelle à un service par l'intermédiaire d'un moteur de recherche client, ledit moteur transmettant en outre la requête avec ladite requête additionnelle afin que le profil élaboré par ledit service pour l'utilisateur soit brouillé par lesdites requêtes ; ladite application comprenant en outre au moins un module d'élaboration d'un profil brouillé pour l'utilisateur à partir des requêtes transmises et un module de validation comprenant des moyens pour interagir avec ledit module d'élaboration afin de valider en fonction dudit profil brouillé des requêtes additionnelles générées ultérieurement avant leur transmission audit service. Selon un troisième aspect, l'invention propose une architecture comprenant : - un service comprenant des moyens pour recevoir des requêtes qu'un utilisateur envoie, ledit service comprenant en outre au moins un module pour élaborer un profil pour ledit utilisateur à partir desdites requêtes ; - un moteur de recherche client comprenant des moyens pour recevoir une requête envoyée par un utilisateur ; - un module d'analyse des éléments de la requête, ledit module comprenant des moyens pour sélectionner les éléments les plus pertinents à partir de ladite analyse ; - un module de rassemblement d'éléments liés auxdits éléments sélectionnés ; - un module de génération d'au moins une requête additionnelle à partir desdits éléments rassemblés ; ledit moteur de recherche client comprenant en outre des moyens de transmission de ladite requête additionnelle avec la requête audit service afin que le profil élaboré par ledit service soit brouillé par lesdites requêtes, ladite architecture comprenant en outre au moins un module d'élaboration d'un profil brouillé pour l'utilisateur à partir des requêtes transmises audit service et un module de validation comprenant des moyens pour interagir avec ledit module d'élaboration afin de valider en fonction dudit profil brouillé des requêtes additionnelles générées ultérieurement avant leur transmission audit service. D'autres particularités et avantages de l'invention apparaîtront dans la description qui suit, faite en référence aux figures annexées, dans lesquelles : - la figure 1 est une représentation schématique d'une architecture d'un réseau, ladite architecture comprenant des moyens pour la mise en oeuvre d'un procédé selon un mode de réalisation de l'invention ; - la figure 2 est une représentation schématique des étapes d'un procédé selon l'invention. En relation avec ces figures, on décrit ci-dessous une architecture pour un réseau, ladite architecture comprenant un service 1 qui comprend des moyens pour recevoir des requêtes qu'un utilisateur 2 envoie, afin d'obtenir des données relatives à ses centres d'intérêt. En outre, le service 1 comprend au moins un module pour élaborer un profil pour l'utilisateur 2 à partir des requêtes dudit utilisateur. Le service 1 peut être par exemple un service de fourniture d'un moteur de recherche tel que Google®. Pour protéger la vie privée de l'utilisateur 2, l'architecture comprend des moyens pour mettre en oeuvre un procédé de brouillage du profil de l'utilisateur 2 selon l'invention. Le procédé prévoit, lorsque l'utilisateur 2 envoie une requête I, d'analyser les éléments E1-E5 de ladite requête pour sélectionner les éléments les plus pertinents. En particulier, les éléments E1-E5 peuvent être des mots, des noms ou encore des verbes. Pour ce faire, l'architecture comprend un moteur de recherche client 3 comprenant des moyens pour recevoir la requête I et un module 4 d'analyse des éléments E1-E5 de ladite requête, ledit module comprenant des moyens pour sélectionner les éléments les plus pertinents à partir de ladite analyse. En relation avec la figure 1, le moteur de recherche client 3 comprend des moyens pour envoyer une notification 5 au module 4, ladite notification comprenant les éléments E1-E5 de la requête I. En relation avec la figure 2, le module 4 agit comme un filtre et sélectionne les éléments E1, E2, E4 les plus pertinents en fonction du potentiel présenté par lesdits éléments pour engendrer un maximum d'ambiguïté, afin de brouiller le profil élaboré par le module du service 1. En particulier, un élément pertinent E1, E2, E4 est sélectionné relativement au nombre d'éléments liés audit élément pertinent et/ou à la nature lexicale des liaisons entre ledit élément pertinent et lesdits éléments liés. Pour ce faire, l'architecture comprend en outre un module 6 de fourniture d'un dictionnaire, par exemple le petit Robert®, le dictionnaire en ligne WordNet®, ou encore le dictionnaire en ligne fourni par le Centre National des Ressources Textuelles et Lexicales (CNRTL). En relation avec la figure 1, le module 4 interagit avec le module 6 pour obtenir, pour chaque élément E1-E5 de la requête I, le nombre d'éléments liés audit élément et/ou la nature de la liaison lexicale entre lesdits éléments. Par exemple, un élément lié à un élément peut être un homonyme, un antonyme, un paronyme, ou au contraire un synonyme, un hyperonyme ou un hyponyme dudit élément. En particulier, les moyens de sélection du module 4 peuvent être agencés pour sélectionner comme pertinents les éléments E1-E5 présentant le plus grand nombre d'éléments liés qui présentent un sens lexical différent, voire contraire, c'est-à-dire un homonyme ou un antonyme. Pour ce faire, ces moyens peuvent être agencés pour compter, pour chaque élément E1-E5, le nombre d'homonymes et pour vérifier si ledit élément présente un antonyme. En outre, pour augmenter davantage le potentiel d'ambiguïté, le module 4 peut sélectionner les éléments pertinents El -E5 en tenant compte des éventuelles erreurs humaines que peut faire l'utilisateur 2 en créant une requête, par exemple une faute de frappe. Pour ce faire, les moyens de sélection peuvent également être agencés pour compter, pour chaque élément E1-E5, le nombre de paronymes. Le procédé prévoit ensuite de rassembler des éléments liés aux éléments pertinents E1, E2, E4 sélectionnés. Pour ce faire, l'architecture comprend un module 7 de rassemblement de tels éléments liés, auquel le module 4 envoie une notification 8 comprenant les éléments pertinents E1, E2, E4. Le module 7 est agencé pour sélectionner, parmi les éléments liés, les alternatives L1-L10 les plus crédibles et pour rassembler lesdites alternatives en au moins un sous ensemble ordonné. Pour ce faire, le module 7 comprend des moyens pour interagir avec le module 6 afin de compter, pour chaque élément lié, le nombre de synonymes, d'hyperonymes, d'hyponymes, ainsi que le nombre de mots appartenant au même champ lexical. Le module 7 comprend en outre des moyens pour classer les éléments liés en fonction du nombre compté précédemment, ainsi que des moyens pour choisir, parmi les éléments liés, les alternatives L1-L10 les plus crédibles, notamment relativement audit nombre, qui traduit la richesse sémantique de ladite alternative. De plus, les alternatives L1-L10 peuvent être choisies en fonction de l'éloignement de leur sens lexical par rapport à celui des éléments E1-E5 de la requête I. En outre, le module 7 peut être agencé pour choisir les alternatives L1-L10 en fonction de règles prédéterminées. Par exemple, si l'un des éléments liés sélectionnés comme alternatives L1-L10 est un antonyme d'un élément E1-E5, le module 7 peut être agencé pour ne pas choisir que des homonymes d'un sujet donné en plus dudit antonyme, car cela rendrait le brouillage inefficace et permettrait au service 1 d'identifier facilement le sujet de la requête I. En particulier, le module 7 peut être agencé pour choisir plusieurs sujets et leurs antonymes. Le module 7 comprend par ailleurs des moyens pour regrouper les alternatives L1-L10, notamment si lesdites alternatives ont des sujets en commun. Pour ce faire, le module 7 peut interagir avec le module 6 pour voir si des alternatives L1-L10 ont des sujets en commun. En relation avec la figure 2, si les alternatives L8, L9, par exemple le mot « Java » en tant que style de musique et le mot « Wolf » en tant que nom d'un groupe de musiciens, ont un sujet relatif en commun, par exemple la musique, lesdites alternatives seront regroupées. Le procédé prévoit en outre de générer au moins une requête additionnelle A1- A10 à partir des alternatives L1-L10 rassemblées. Pour ce faire, l'architecture comprend un module 9 de génération d'au moins une telle requête additionnelle A1-A10, auquel le module 7 envoie une notification 10 comprenant le sous- ensemble d'alternatives L1-L10 qu'il a rassemblées. En particulier, ce sous-ensemble peut se présenter sous la forme d'une liste de mots L1-L10. En relation avec les figures, le module 9 comprend des moyens pour interagir avec le module 6 afin d'obtenir, pour chaque alternative L1-L10, les synonymes, les hyperonymes, les hyponymes et/ou les mots appartenant au même champ lexical, ainsi que des moyens pour générer une requête additionnelle A1-A10 pour chaque alternative L1-L10 en regroupant ladite alternative avec ses synonymes, hyperonymes, hyponymes et/ou les mots de son champ lexical. Dans le mode de réalisation représenté, l'architecture comprend une application 16 qui comprend un module 4 d'analyse, un module 7 de rassemblement et un module 9 de génération. En outre, l'application 16 comprend un module 6 de fourniture d'un dictionnaire. Le procédé prévoit en outre de transmettre la requête additionnelle A1-A10 avec la requête I au service 1 afin que le profil élaboré pour l'utilisateur 2 par le module dudit service soit brouillé par lesdites requêtes. Pour ce faire, le moteur de recherche client 3 comprend des moyens de transmission des requêtes I, Al -A10 au service 1. En relation avec la figure 1, l'application 16 comprend en outre des moyens pour transmettre les requêtes additionnelles A1-A10 générées au service 1 par l'intermédiaire du moteur de recherche client 3 et ledit moteur envoie au service 1 un groupe 23 comprenant l'ensemble des requêtes I, A1-A10. Pour améliorer le brouillage du profil de l'utilisateur, le procédé prévoit en outre d'utiliser les requêtes I, A1-A10 transmises au service 1 pour élaborer au moins un profil brouillé et de valider en fonction dudit profil brouillé les requêtes additionnelles A1-A10 générées ultérieurement avant leur transmission audit service. Pour ce faire, l'architecture comprend au moins un module 13 d'élaboration d'un profil brouillé pour l'utilisateur 2 à partir des requêtes I, Al -A10 transmises au service 1, ainsi qu'un module 11 de validation comprenant des moyens pour interagir avec le module 13 afin de valider en fonction dudit profil brouillé des requêtes additionnelles Al -A10 générées ultérieurement avant leur transmission au service 1. En relation avec la figure 1, l'architecture comprend également un module 12 d'élaboration d'un vrai profil pour l'utilisateur 2 en plus du module 13 d'élaboration d'un profil brouillé. Ces modules 12, 13 comprennent chacun des moyens pour analyser l'historique de l'activité de l'utilisateur 2 dans le réseau, par exemple en utilisant des algorithmes classiques d'élaboration de profils. En particulier, le module 12 comprend des moyens pour analyser l'historique des anciennes requêtes I envoyées par l'utilisateur 2 et le module 13 comprend des moyens pour analyser l'historique de l'ensemble des anciennes requêtes I, Al -Al 0 transmises par le moteur de recherche client 3. Pour ce faire, le moteur de recherche client 3 peut être agencé pour envoyer les requêtes I, Al -A10 qu'il a transmises au service 1 aux modules 12, 13, ainsi que des informations relatives au type desdites requêtes, c'est-à-dire s'il s'agit de requêtes I de l'utilisateur 2 ou de requêtes additionnelles Al -Al 0, afin que lesdits modules gardent localement une trace desdites requêtes pour pouvoir élaborer respectivement le vrai profil et le profil brouillé. En outre, les modules 12, 13 comprennent respectivement un historique 14, 15 dans lesquels sont stockés respectivement les anciennes requêtes I de l'utilisateur 2 et l'ensemble des anciennes requêtes I, Al -A10 transmises par le moteur de recherche client 3, ainsi que respectivement le vrai profil et le profil brouillé. Le module 11 comprend des moyens pour interagir avec les modules 12, 13 afin de comparer une requête additionnelle Al -A10 générée avec le vrai profil et le profil brouillé de l'utilisateur 2 et de valider en fonction de ladite comparaison ladite requête additionnelle avant sa transmission au service 1. En particulier, si le sujet d'une requête additionnelle Al -Al 0 est trop proche du vrai profil et/ou trop éloignée du profil brouillé pour permettre un brouillage efficace du profil élaboré par le système 1, le module 11 peut comprendre des moyens pour notifier ladite requête additionnelle comme étant indésirable et des moyens pour enregistrer ladite requête additionnelle dans une base de données dite liste noire, afin que le module 9 ne génère plus ladite requête additionnelle. En outre, le module 11 ne validera pas cette requête additionnelle Al -Al O. En relation avec la figure 1, le module 11 envoie à l'application 16 une notification 17 indiquant qu'une requête additionnelle Al -A10 générée est indésirable, l'application 16 enregistrant alors ladite requête additionnelle dans une liste noire 18 et interagissant avec les modules 4, 6, 7, 9 pour générer de nouvelles requêtes additionnelles Al -Al O. En relation avec la figure 2, si la requête additionnelle A6 a été générée à partir du mot L6 « Wolf » désignant en anglais le loup en tant qu'animal et si la requête I contenait déjà un mot E4 désignant le loup en tant qu'animal, la requête additionnelle A6 est trop proche du vrai profil de l'utilisateur 2 et supprimée de la liste de requêtes additionnelles Al -A10. L'application 16 interagit alors avec les modules 4, 6, 7, 9 pour construire une nouvelle requête additionnelle A7 à partir d'une nouvelle alternative L7 liée au mot E4, par exemple le mot « doux », qui est un antonyme de « bestial ». En outre, si deux requêtes additionnelles Al -A10 présentent une crédibilité sémantique égale, mais que l'une desdites requêtes additionnelles a déjà été répertoriée dans l'historique 15 et n'a de plus jamais été répertoriée dans l'historique 14, le module 11 peut être agencé pour valider en priorité cette requête additionnelle Al -Al O. En variante non représentée, le module 11 et/ou les modules 12, 13 peuvent être intégrés dans l'application 16 et le module 11 peut comprendre en outre des moyens pour interagir avec le module 7, afin que le module 7 choisisse les alternatives L1-L10 les plus crédibles en fonction d'un indice de similitude de chacune desdites alternatives avec le vrai profil et/ou le profil brouillé de l'utilisateur 2. Le procédé peut en outre prévoir au moins une étape supplémentaire de validation des requêtes additionnelles Al -A10 avant leur transmission au service 1. En particulier, le procédé peut prévoir d'évaluer une popularité pour la requête additionnelle Al -A10 et de comparer ladite popularité avec la popularité de la requête I, ladite requête additionnelle étant validée en fonction de ladite comparaison. Pour ce faire, l'architecture comprend un module 19 d'évaluation d'une popularité pour la requête additionnelle, ledit module comprenant des moyens pour comparer ladite popularité avec la popularité de la requête I et des moyens pour valider ladite requête additionnelle en fonction de ladite comparaison. En effet, pour que le brouillage du profil élaboré par le service 1 soit efficace, toutes les requêtes Al -Al 0, I transmises audit service doivent présenter des popularités équivalentes, par exemple relativement aux valeurs statistiques calculées par le module d'élaboration de profil dudit service, et ce afin d'éviter que ledit module n'identifie la requête I en explorant les données stockées dans l'historique de recherches de l'utilisateur 2. Pour évaluer la popularité des requêtes Al -A10, I, les moyens dédiés du module 19 peuvent notamment être agencés pour interagir avec des outils connus tels que par exemple Google Trends®, qui fournissent des indices de popularité pour chaque élément d'une requête pour une période de temps donnée. En particulier, de tels outils peuvent être installés par avance dans l'architecture par un administrateur. De plus, le module 19 peut être agencé pour faire interagir ces outils avec le module 6 de fourniture d'un dictionnaire afin d'évaluer la popularité des mots contenus dans ledit dictionnaire. Si les requêtes Al -A10, I ne présentent pas des popularités égales, par exemple si des requêtes additionnelles Al -A10 présentent une popularité supérieure à celle de la requête I, le module 19 ne valide pas ces requêtes additionnelles Al -Al 0, qui sont alors supprimées de l'ensemble de requêtes Al -Al 0 à transmettre. En relation avec la figure 1, si après la suppression des requêtes additionnelles Al -Al 0 indésirables, l'ensemble restant n'est pas suffisamment important pour assurer un brouillage efficace, le module 19 envoie à l'application 16 une notification 20 afin que ladite application interagisse avec les modules 4, 6, 7, 9 pour générer de nouvelles requêtes additionnelles Al-Al 0. En variante non représentée, le module 19 peut être intégré dans l'application 16 et peut comprendre en outre des moyens pour interagir avec les modules 7 et 9, afin que le module 7 choisisse les alternatives L1-L10 les plus crédibles en fonction d'un indice de popularité de chacune desdites alternatives et que le module 9 génère des requêtes additionnelles Al -Al 0 avec lesdites alternatives. Le procédé peut prévoir en outre une intervention de l'utilisateur 2 pour valider la requête additionnelle Al -A10 préalablement à sa transmission avec la requête I au service 1. Pour ce faire, l'architecture comprend un module 21 de fourniture d'une interface graphique (GUI, pour Graphical User Interface) à l'utilisateur 2 afin de permettre audit utilisateur d'intervenir pour valider la requête additionnelle Al -Al 0. L'interface fournie est agencée pour présenter les requêtes additionnelles Al - Al 0 générées à l'utilisateur 2 et pour proposer audit utilisateur de valider ou de supprimer lesdites requêtes. Les requêtes Al -Al 0, I peuvent notamment être présentées par le biais d'un premier graphique représentant schématiquement le degré d'incertitude que l'ensemble de requêtes Al -Al 0, I est susceptible de créer au niveau du service 1, ledit degré étant par exemple indiqué par une distance sémantique moyenne calculée entre la requête I et les requêtes additionnelles Al -A10 et/ou une distance sémantique moyenne calculée entre lesdites requêtes additionnelles et le vrai profil et/ou le profil brouillé de l'utilisateur 2. Les requêtes Al -A10, I peuvent en outre être présentées par le biais d'un second graphique se présentant sous la forme d'une liste répertoriant chaque requête additionnelle Al -A10 avec sa distance sémantique par rapport à la requête I et/ou par rapport au vrai profil et/ou au profil brouillé de l'utilisateur 2. Ainsi, en interagissant avec l'interface, l'utilisateur 2 peut valider ou supprimer des requêtes additionnelles Al -Al 0, la suppression de requêtes additionnelles Al -Al 0 entraînant des modifications en temps réel sur le premier graphique. En effet, le degré d'incertitude indiqué sur ce premier graphique étant d'autant plus important que le nombre de requêtes additionnelles Al -A10 est important, ledit degré diminuera si l'utilisateur 2 supprime des requêtes additionnelles Al -Al O. En outre, si l'ensemble de requêtes additionnelles Al -A10 validées par l'utilisateur 2 n'est pas suffisant, l'utilisateur 2 peut interagir avec l'interface pour que de nouvelles requêtes additionnelles Al -A10 soient générées. En relation avec la figure 1, le module 21 envoie alors une notification 22 à l'application 16 afin que ladite application interagisse avec les modules 4, 6, 7, 9 pour générer de nouvelles requêtes additionnelles Al -Al O. En particulier, l'utilisateur 2 peut vouloir supprimer une requête additionnelle Al -Al 0 s'il a par exemple des centres d'intérêts se rapprochant trop du sujet de ladite requête additionnelle. De plus, l'utilisateur 2 peut vouloir supprimer une requête additionnelle Al -A10 si ladite requête additionnelle présente un sujet qui pourrait nuire à la réputation dudit utilisateur si cette requête additionnelle Al -A10 venait à être utilisée pour brouiller le profil élaboré par le service 1 pour l'utilisateur 2. De même, l'utilisateur 2 peut vouloir supprimer une requête additionnelle A1-A10 si ladite requête anticipe involontairement les requêtes que ledit utilisateur comptait envoyer ultérieurement au service 1. En relation avec la figure 2, si la requête additionnelle A3 a été générée à partir du mot L3 « Ireland » désignant en anglais l'Irlande et si l'utilisateur 2 comptait envoyer ultérieurement des requêtes pour obtenir des informations sur l'Irlande, par exemple pour préparer un voyage, il peut supprimer ladite requête additionnelle. Le module 21 peut comprendre en outre des moyens pour permettre à l'utilisateur 2 d'accéder au vrai profil et au profil brouillé stockés respectivement dans les historiques 14, 15. Ainsi, l'utilisateur 2 peut modifier l'ensemble de requêtes additionnelles Al -A10 à transmettre de façon à personnaliser son profil brouillé à sa guise, par exemple pour insister sur de faux centres d'intérêts ou pour éviter des similarités entre le profil brouillé actuel et le vrai profil. De plus, le module 21 peut comprendre des moyens pour mémoriser dans une base de données les préférences de l'utilisateur 2 relativement aux interactions qu'il a menées, afin d'appliquer ultérieurement lesdites préférences par défaut. En variante non représentée, le module 21 peut être intégré dans l'application 16 et peut comprendre en outre des moyens pour interagir avec le module 7 afin de fournir à l'utilisateur 2 une interface graphique dans laquelle sont présentés les alternatives L1-L10 choisies par le module 7, l'utilisateur 2 interagissant avec ladite interface pour modifier et/ou valider lesdites alternatives, le module 9 générant alors des requêtes additionnelles Al -A10 à partir desdites alternatives. Une fois les requêtes additionnelles validées, le module 21 envoie au moteur de recherche client 3 une notification 24 comprenant l'ensemble des requêtes I, Al -Al 0, afin que ledit moteur de recherche client transmette ledit ensemble au service 1 et que le profil élaboré pour l'utilisateur 2 soit brouillé par ledit ensemble. En réponse à chacune des requêtes I, Al -A10, le service 1 fournit une liste d'adresses interactives (URL, pour l'anglais Uniform Ressource Locator), de telles adresses permettant notamment à l'utilisateur 2d'accéder à des pages Internet, par exemple en interagissant au moyen de sa souris avec une desdites adresses. En relation avec la figure 1, le moteur de recherche client 3 comprend en outre des moyens pour envoyer au moins une notification 25 au service 1, ladite notification comprenant des informations pour provoquer une interaction aléatoire avec une adresse de la liste fournie par ledit service, afin que ladite interaction soit enregistrée dans l'historique d'utilisation dudit service et que le profil élaboré pour l'utilisateur 2 soit brouillé par ladite interaction. Selon une réalisation, le moteur de recherche client 3, l'application 16 et/ou les modules 4, 6, 7, 9, 11-13, 19 et 21 peuvent être intégrés dans une plateforme d'un navigateur de fourniture d'un accès à un réseau, afin que ledit navigateur fournisse à ses utilisateurs 2 une option permettant de préserver leur vie privée lorsqu'ils utilisent un service 1, ladite option permettant de brouiller le profil élaboré par le service 1 par mise en oeuvre du procédé selon l'invention. En variante, l'ensemble des moyens décrits ci-dessus peuvent être intégrés dans un routeur ou dans une passerelle locale, afin de permettre aux fournisseurs d'accès à Internet de préserver la vie privée des utilisateurs 2 indépendamment du navigateur utilisé par lesdits utilisateurs. Selon une autre variante, l'ensemble de ces moyens peuvent être intégrés dans un dispositif local connecté à une passerelle locale, ledit dispositif interceptant l'ensemble des requêtes I, Al -Al 0 entrantes et sortantes.30 REVENDICATIONS1. Procédé de brouillage du profil d'un utilisateur (2) élaboré par un service (1) à partir de requêtes que ledit utilisateur envoie audit service, ledit procédé prévoyant, lorsque ledit utilisateur envoie une requête (I), d'analyser les éléments (El -E5) de ladite requête pour sélectionner les éléments (El, E2, E4) les plus pertinents, de rassembler des éléments (L1 -L10) liés auxdits éléments sélectionnés, de générer au moins une requête additionnelle (Al -A10) à partir desdits éléments rassemblés et de transmettre ladite requête additionnelle avec la requête (I) audit service afin que le profil soit brouillé par lesdites requêtes, ledit procédé prévoyant en outre d'utiliser les requêtes (I, Al -A10) transmises audit service pour élaborer au moins un profil brouillé et de valider en fonction dudit profil brouillé les requêtes additionnelles générées ultérieurement avant leur transmission audit service. 2. Procédé selon la revendication 1, caractérisé en ce qu'un élément pertinent (E1, E2, E4) est sélectionné relativement au nombre d'éléments liés (L1-L10) audit élément pertinent et/ou à la nature lexicale des liaisons dudit élément pertinent avec lesdits éléments liés. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il prévoit en outre d'évaluer une popularité pour la requête additionnelle (Al -A10) et de comparer ladite popularité avec la popularité de la requête (I), ladite requête additionnelle étant en outre validée en fonction de ladite comparaison préalablement à la transmission de ladite requête additionnelle et de la requête (I) au service (1). 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il prévoit en outre une intervention de l'utilisateur (2) pour valider la requête additionnelle (Al -A10) préalablement à la transmission de ladite requête additionnelle et de la requête (I) au service (1). 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il prévoit en outre d'utiliser les requêtes (I) transmises au service (1) pour élaborer un vrai profil pour l'utilisateur (2) et de valider en fonction dudit vrai profil les requêtes additionnelles générées ultérieurement avant leur transmission audit service. 6. Application (16) comprenant des moyens pour recevoir une requête (I) envoyée par un utilisateur (2), ladite application comprenant en outre : - un module (4) d'analyse des éléments (E1-E5) de la requête (I), ledit module comprenant des moyens pour sélectionner les éléments (El, E2, E4) les plus pertinents à partir de ladite analyse ; - un module (7) de rassemblement d'éléments (L1-L10) liés auxdits éléments sélectionnés ; - un module (9) de génération d'au moins une requête additionnelle (A1- Al 0) à partir desdits éléments rassemblés ; - des moyens pour transmettre ladite requête additionnelle à un service (1) par l'intermédiaire d'un moteur de recherche client (3), ledit moteur transmettant en outre la requête (I) avec ladite requête additionnelle afin que le profil élaboré par ledit service pour l'utilisateur (2) soit brouillé par lesdites requêtes ; ladite application comprenant en outre au moins un module (13) d'élaboration d'un profil brouillé pour l'utilisateur (2) à partir des requêtes (I, Al -A10) transmises et un module (11) de validation comprenant des moyens pour interagir avec ledit module d'élaboration afin de valider en fonction dudit profil brouillé des requêtes additionnelles (Al -A10) générées ultérieurement avant leur transmission audit service. 7. Application (16) selon la revendication 6, caractérisée en ce qu'elle comprend en outre un module (6) de fourniture d'un dictionnaire, le module (4) interagissant avec le module (6) pour sélectionner un élément pertinent (El, E2, E4) relativement au nombre d'éléments (L1-L10) liés audit élément pertinent et/ou à la nature lexicale des liaisons dudit élément pertinent avec lesdits éléments liés. 8. Application (16) selon la revendication 6 ou 7, caractérisée en ce qu'elle comprend en outre un module (12) d'élaboration d'un vrai profil pour l'utilisateur (2) à partir des requêtes (I) transmises, le module (11) comprenant en outre des moyens pour interagir avec ledit module d'élaboration afin de valider en fonction dudit vrai profil des requêtes additionnelles (Al -Al 0) générées ultérieurement avant leur transmission au service (1). 9. Architecture comprenant : - un service (1) comprenant des moyens pour recevoir des requêtes qu'un utilisateur (2) envoie, ledit service comprenant en outre au moins un module pour élaborer un profil pour ledit utilisateur à partir desdites requêtes ; - un moteur de recherche client (3) comprenant des moyens pour recevoir une requête (I) envoyée par un utilisateur (2) ; - un module (4) d'analyse des éléments (E1-E5) de la requête (I), ledit module comprenant des moyens pour sélectionner les éléments (El, E2, E4) les plus pertinents à partir de ladite analyse ; - un module (7) de rassemblement d'éléments (L1-L10) liés auxdits éléments sélectionnés ; - un module (9) de génération d'au moins une requête additionnelle (Al - Al 0) à partir desdits éléments rassemblés ; ledit moteur de recherche client comprenant en outre des moyens de transmission de ladite requête additionnelle avec la requête (I) audit service afin que le profil élaboré par ledit service soit brouillé par lesdites requêtes, ladite architecture comprenant en outre au moins un module (13) d'élaboration d'un profil brouillé pour l'utilisateur (2) à partir des requêtes (I, Al -Al 0) transmises audit service et un module (11) de validation comprenant des moyens pour interagir avec ledit module d'élaboration afin de valider en fonction dudit profil brouillé des requêtes additionnelles (Al -A10) générées ultérieurement avant leur transmission audit service. 10. Architecture selon la revendication 9, caractérisée en ce qu'elle comprend en outre un module (6) de fourniture d'un dictionnaire, le module (4)interagissant avec le module (6) pour sélectionner un élément pertinent (E1, E2, E4) relativement au nombre d'éléments (L1-L10) liés audit élément pertinent et/ou à la nature lexicale des liaisons dudit élément pertinent avec lesdits éléments liés. 11. Architecture selon la revendication 9 ou 10, caractérisée en ce qu'elle comprend en outre un module (19) d'évaluation d'une popularité pour la requête additionnelle (Al -A10), ledit module comprenant des moyens pour comparer ladite popularité avec la popularité de la requête (I) et des moyens pour valider ladite requête additionnelle en fonction de ladite comparaison préalablement à la transmission de ladite requête additionnelle et de la requête (I) au service (1). 12. Architecture selon l'une quelconque des revendications 9 à 11, caractérisée en ce qu'elle comprend en outre un module (21) de fourniture d'une interface graphique GUI à l'utilisateur (2) afin de permettre audit utilisateur d'intervenir pour valider la requête additionnelle (Al -Al 0) préalablement à la transmission de ladite requête additionnelle et de la requête (I) au service (1). 13. Architecture selon l'une quelconque des revendications 9 à 12, caractérisée en ce qu'elle comprend en outre un module (12) d'élaboration d'un vrai profil pour l'utilisateur (2) à partir des requêtes (I) transmises au service (1), le module (11) comprenant des moyens pour interagir avec ledit module d'élaboration afin de valider en fonction dudit vrai profil des requêtes additionnelles (Al -Al 0) générées ultérieurement avant leur transmission audit service.