La présente invention se rapporte à un système et à un procédé d'accès à un service, sur un réseau de type Internet. L'invention s'applique plus précisément aux services pour lesquels le fournisseur de service est susceptible de demander des informations personnelles à l'utilisateur avant de lui rendre ce service. Ces informations personnelles (aussi appelées attributs) servent, par exemple, à personnaliser un service en fonction de l'utilisateur. Généralement, les attributs sont détenus par le fournisseur d'accès au réseau Internet ou stockés sur un serveur baptisé ci-après « serveur d'informations personnelles ». Il arrive parfois que le détenteur ou le fournisseur de ces informations personnelles ait la nécessité de contacter l'utilisateur pour lui demander son accord formel pour partager ou diffuser certaines de ces informations. On parle alors « d'interaction ». Ponctuellement, ce mécanisme d'interaction peut aussi être utilisé pour demander à l'utilisateur un nouvel attribut, ou la mise à jour d'un attribut. Les mécanismes d'interaction connus à ce jour ne sont destinés qu'aux terminaux mobiles et reposent sur un procédé de communication de type SMS ou Push WAP. L'invention vise à généraliser ce mécanisme d'interaction à tous types de terminaux adaptés à mettre en oeuvre le protocole de communication HTTP. Dans la suite de ce document, nous ferons référence à une architecture de type client/serveur connue de l'homme du métier, étant rappelé que dans une telle architecture, on appelle « client », tout module logiciel ou matériel adapté à émettre des requêtes vers un « serveur », et à obtenir, en retour, des réponses de ce serveur. Plus précisément, l'invention concerne un système d'accès à un service sur un réseau de type Internet, ce système comportant au moins : - un poste d'utilisateur équipé d'un navigateur Internet et relié au réseau via un serveur proxy, ce serveur proxy comportant un client adapté à mettre en œuvre un protocole permettant la modification de requêtes et de réponses HTTP ; - un serveur d'informations personnelles ; - un fournisseur de service relié au réseau et apte à émettre, vers Ie poste utilisateur, une requête pour obtenir une information personnelle de cet utilisateur ; et - un serveur de modification de requêtes et de réponses raccordé audit réseau, et : - adapté à mettre en œuvre le protocole précité ; - rediriger la requête vers le serveur d'informations personnelles ; - recevoir l'information personnelle en provenance du serveur d'informations personnelles ; et - retransmettre cette information personnelle au fournisseur de service ; ce système d'accès étant caractérisé en ce que, pour obtenir l'information personnelle : - le serveur d'informations personnelles émet une requête d'interaction en direction du poste utilisateur, cette requête étant relayée par le serveur de modification de requêtes et de réponses ; - la réponse de l'utilisateur à cette requête d'interaction étant transmise en retour au serveur d'informations personnelles via le serveur de modification de requêtes et de réponses. Dans la suite de la description, et dans un souci de concision, le serveur de modification de requêtes et de réponses sera appelé « serveur de modification ». Conformément à l'invention, le serveur d'informations personnelles interroge donc explicitement l'utilisateur, lorsque un accord formel de cet utilisateur lui est nécessaire, par exemple avant la diffusion d'une information. Avantageusement, le protocole permettant la modification de requêtes et de réponses HTTP utilisé dans l'invention est le protocole iCAP normalisé par PIETF (Internet Engineering Task Force). Dans ce cas, l'homme du métier comprendra que le serveur proxy comporte un client iCAP, le serveur de modification étant constitué par un serveur iCAP. L'invention, qui repose alors sur le protocole iCAP standardisé, est particulièrement aisée à mettre en œuvre, et peut être utilisée par des serveurs proxy et des serveurs d'informations personnelles dès lors qu'ils implémentent ce protocole. Dans une première variante de réalisation, le serveur proxy relaye également la requête d'interaction, et la réponse à cette requête d'interaction, au cours des échanges qui ont lieu entre le serveur de modification et le poste utilisateur. Dans une deuxième variante de réalisation, le poste d'utilisateur comporte un serveur HTTP adapté à recevoir la requête d'interaction, sous forme d'une requête HTTP, mise en forme et transmise par le serveur de modification. Dans un mode préféré de cette deuxième variante de réalisation, le système d'accès selon l'invention comporte des moyens de filtrage de la requête d'interaction HTTP. Ces moyens de filtrage, qui peuvent notamment être incorporés dans le serveur proxy et/ou dans le serveur HTTP du poste client, permettent de vérifier que la requête d'interaction provient d'un serveur d'informations personnelles autorisé. Préférentiellement, lorsque ce n'est pas le cas, ces moyens de filtrage rejettent la requête d'interaction. Dans un mode préféré de réalisation, le serveur proxy est hébergé chez le fournisseur d'accès auquel le poste utilisateur doit se connecter pour accéder au réseau. Corrélativement, l'invention vise un procédé d'accès à un service sur un réseau de type Internet, ce procédé comportant : - une étape d'envoi, par un poste d'utilisateur, d'une requête d'accès à un fournisseur de service ; - une étape d'envoi, par le fournisseur de service, d'une requête, vers le poste utilisateur, pour obtenir une information personnelle de cet utilisateur ; - une étape de redirection de cette requête, par un serveur de modification adapté à mettre en œuvre un protocole permettant la modification de requêtes et de réponses HTTP, vers un serveur d'informations personnelles ; - une étape d'obtention de l'information personnelle par ce serveur d'informations personnelles et ; - une étape de transmission de cette information personnelle au fournisseur de service, via le serveur de modification ; ce protocole d'accès étant caractérisé en ce que l'étape d'obtention comporte : - une étape d'émission, par le serveur d'informations personnelles, d'une requête d'interaction relayée, vers le poste utilisateur, par le serveur de modification ; et - une étape de réponse de l'utilisateur à cette requête d'interaction, la réponse étant transmise en retour au serveur d'informations personnelles via le serveur de modification. Les avantages particuliers du procédé d'accès étant identiques à ceux du système introduit précédemment, ils ne seront pas rappelés ici. D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description de modes particuliers de réalisation qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés sur lesquels : - la figure 1 représente de façon schématique un système d'accès conforme à l'invention dans une première variante de réalisation ; - la figure 2 représente, sous forme d'organigramme, les principales étapes d'un procédé d'accès mis en œuvre dans le système de la figure 1 ; et - la figure 3 représente, de façon schématique, le flux d'informations entre les différents équipements du système d'accès de la figure 1. La figure 1 représente un système d'accès à un réseau 5 de type Internet dans une première variante de réalisation. Ce système comporte au moins un poste d'utilisateur 10 équipé d'un navigateur Internet 15, ce poste 10 étant relié au réseau Internet 5, via un serveur proxy 20. Dans le mode préféré de réalisation décrit ici, le serveur proxy 20 est hébergé chez un fournisseur d'accès 25 auquel le poste utilisateur 10 doit se connecter pour accéder au réseau 5. Ce fournisseur d'accès 25 comporte également un serveur de contrôle d'accès 30 capable d'authentifier l'utilisateur du poste 10, par exemple à partir d'un identificateur (login) et d'un mot de passe, et à fournir une adresse IP (Internet Protocol) au poste 10 pour que celui-ci puisse naviguer sur le réseau Internet 5. Une fois cette adresse IP délivrée, toutes les requêtes et les réponses HTTP (Hyper Text Transfer Protocol) émises et reçues par le poste utilisateur 10 pour accéder au réseau 5 transitent via le serveur proxy 20. Conformément à l'invention, le système d'accès décrit ici comporte un serveur 35 susceptible de mémoriser, dans une mémoire 40, au moins une information personnelle de l'utilisateur du poste 10. De telles informations personnelles, autrement appelées « attributs », sont par exemple constituées par une date de naissance, ou un mot clef choisi par l'utilisateur. En référence à la figure 3, le système d'accès comporte aussi un fournisseur de service 45 relié au réseau 5, pour rendre des services à l'utilisateur du poste 10, en réponse à une requête d'accès M1 relayée par le serveur proxy 20 sous la forme d'une requête M2. De façon connue, ce fournisseur de service 45 est susceptible, avant de rendre ledit service, d'émettre, en direction du poste utilisateur 10, une requête M3 incluse dans une réponse HTTP, pour obtenir une information personnelle de cet utilisateur. Le système selon l'invention comporte également, raccordé au réseau Internet 5, un serveur 50 baptisé « serveur de modification » et adapté à mettre en œuvre un protocole permettant la modification de requêtes et de réponses HTTP. Dans le mode préféré de réalisation décrit ici, ce serveur 50 est constitué par un serveur iCAP 50 (Internet Content Adaptation Protocol) adapté à mettre en œuvre le protocole iCAP. Conformément à l'invention, le serveur proxy 20 comporte un client 55 adapté à mettre en œuvre le même protocole que le serveur de modification 50, à savoir ici le protocole iCAP. Conformément à l'invention, le client iCAP 55 du serveur proxy 20 est configuré pour transmettre au serveur iCAP 50 les requêtes M3 d'obtention d'informations personnelles. Ainsi, lorsque le serveur proxy 20 voit passer la requête M3 d'obtention d'informations personnelles destinée au poste utilisateur 10, il intercepte cette requête et l'envoie (requête iCAP M4) au serveur iCAP, en utilisant le protocole iCAP. Conformément à l'invention, le serveur iCAP 50 est adapté à rediriger cette requête M4, (requête M5) vers le serveur d'informations personnelles 35. Si le serveur d'informations personnelles 35 possède l'information personnelle de l'utilisateur 10, il répond à cette requête M5 en envoyant une réponse HTTP M6 comportant cette information personnelle. Cette réponse M6 est reçue par le serveur iCAP 50 puis retransmise, sous la forme d'une réponse M7 incluse dans une requête POST HTTP, au fournisseur de service 45. Nous nous plaçons maintenant dans le cas où le serveur d'informations personnelles 35 nécessite une interaction avec l'utilisateur du poste 10, pour obtenir son accord formel avant la diffusion d'une donnée personnelle, ou, ponctuellement, pour obtenir un nouvel attribut. Dans ce cas, le serveur d'informations personnelles 35 émet une requête d'interaction Ma, incluse dans une réponse HTTP, vers le poste utilisateur 10, cette requête étant relayée sous la forme d'une requête Mb par le serveur iCAP 50. Préférentiellement, la requête d'interaction Mb, envoyée par le serveur iCAP 50 au poste 10 se compose principalement d'une page web affichable par le navigateur Internet 15, cette page web comportant par exemple des zones de saisie d'un ordre formel de diffusion d'une information personnelle (par exemple une date de naissance) et un lien vers le serveur iCAP 50. Dans un mode préféré de cette première variante de réalisation, la requête d'interaction Mb est également relayée, sous la forme d'une requête Mc, par le serveur proxy 20. Lorsque l'utilisateur du poste 10 actionne le lien de cette page Web, une réponse Md à la requête d'interaction Mc est envoyée, par un client HTTP du navigateur 15, au serveur iCAP 50. Optionnellement, cette réponse est relayée sous la forme d'une réponse Me par le serveur proxy 20. Cette réponse est ensuite transmise par le serveur iCAP 50 au serveur d'informations personnelles 35 sous la forme d'une réponse Mf. Nous allons maintenant décrire, en référence aux figures 2 et 3, les principales étapes d'un procédé d'accès mis en œuvre par le système de la figure 1 et le flux d'informations entre les différents équipements de ce système dans un mode préféré de réalisation. Le procédé selon l'invention comporte une première étape E10 au cours de laquelle l'utilisateur du poste 10, voulant se connecter au réseau 5, transmet une requête d'authentification au serveur de contrôle d'accès 30 du fournisseur d'accès 25. Si cette requête d'authentification est valide, le serveur de contrôle d'accès 30 fournit, lors d'une étape E20, une adresse IP au poste d'utilisateur 10 lui donnant ainsi accès au réseau Internet 5. Nous supposerons qu'à l'issue de cette étape E20 d'autorisation d'accès, l'utilisateur souhaite accéder à un service fourni par le fournisseur de service 45. Le poste 10 envoie, à cet effet, au cours d'une étape E30, une requête d'accès M1 au fournisseur de service 45, cette requête M1 étant relayée par le serveur proxy 20 puis transmise sous la forme d'une requête M2 au fournisseur de service 45. Cette étape E30 de demande de service est suivie par une étape E40 au cours de laquelle le fournisseur de service 45 émet une requête M3 d'obtention d'informations personnelles à destination du poste utilisateur 10, cette requête M3 étant incluse dans une réponse HTTP. Cette requête M3 est interceptée au cours d'une étape E50 par le serveur proxy 20 puis envoyée, vers le serveur iCAP 50, sous la forme d'une requête M4 conforme au protocole iCAP. Cette étape E50 de redirection de la requête d'obtention d'informations personnelles vers le serveur iCAP 50 est suivie par une étape E60 au cours de laquelle le serveur iCAP 50 sélectionne un serveur 35 d'informations personnelles de l'utilisateur 10 et transmet, à ce serveur 35, une requête M5. Cette étape de transmission E60 est suivie par un test E70 au cours duquel le serveur d'informations personnelles 35 vérifie s'il doit contacter l'utilisateur du poste 10 ou non. Si tel n'est pas le cas, le résultat du test E70 est négatif et le serveur d'informations personnelles 35 envoie, au cours d'une étape E110, l'information personnelle demandée dans une réponse HTTP M6, au serveur iCAP 50 qui la retransmet, dans une réponse HTTP M7, au fournisseur de service 45. En revanche, si le serveur d'informations personnelles 35 doit contacter l'utilisateur 10, le résultat du test E70 est positif. Ce test est alors suivi par une étape E80 au cours de laquelle le serveur d'informations personnelles 35 émet une requête d'interaction Ma, incluse dans une réponse HTTP, vers le poste utilisateur 10 via le serveur iCAP 50. Au cours d'une étape E90, cette requête d'interaction Ma est relayée par le serveur iCAP 50 sous forme d'une requête Mb, composée principalement par une page Web. Préférentiellement, au cours de cette même étape E90, le serveur proxy 20 intercepte cette requête HTTP Mb et la transmet au poste utilisateur 10 sous la forme d'une réponse HTTP Mc. L'utilisateur peut ensuite, au cours d'une étape E110, répondre à la requête d'interaction en donnant, dans un champ de la page Web, son accord formel pour la diffusion d'une de ses données personnelles par le serveur d'informations personnelles 35 ou en fournissant, le cas échéant, un nouvel attribut. Pour valider cette opération, l'utilisateur actionne, au cours de cette même étape E110, un lien sur la page Web, ce qui génère l'envoi, par le navigateur 15, d'une réponse Md. Optionnellement, la réponse Md est relayée, sous la forme d'une requête Me par le serveur proxy 20. Quoiqu'il en soit la réponse Md (ou la requête Me) est interceptée par le serveur iCAP 50, puis transférée au serveur d'informations personnelles 35, sous forme d'une requête Mf. Sur réception de la requête Mf, le serveur d'informations personnelles 35 récupère les données saisies par l'utilisateur 10, puis, s'il en est autorisé, envoie l'information personnelle au serveur iCAP 50 sous la forme d'une réponse HTTP M6. Cette réponse M6 est reçue par le serveur iCAP 50 puis retransmise, sous la forme d'une réponse M7 incluse dans une requête POST HTTP, au fournisseur de service 45. Nous allons maintenant décrire un système d'accès conforme à l'invention dans une deuxième variante de réalisation. Dans cette variante, le poste d'utilisateur 10 comporte un serveur HTTP, préférentiellement incorporé dans son navigateur 15, adapté à traiter les requêtes d'interaction Mb en provenance du serveur iCAP 50. Dans cette variante de réalisation, un client HTTP du serveur iCAP 50 envoie une requête Mb directement vers le serveur HTTP du poste utilisateur 10, cette requête Mb n'étant pas nécessairement relayée par le serveur proxy 20. Préférentiellement, afin de sécuriser le système, et d'éviter que le serveur HTTP du poste utilisateur 10 ne réponde à des requêtes d'un tiers mal intentionné, ce serveur HTTP ne peut recevoir de requêtes qu'à partir d'une adresse IP connue seulement du fournisseur d'accès 25, attribuée par Ie serveur de contrôle d'accès 30. Dans un mode préféré de cette deuxième variante de réalisation, le procédé d'accès selon l'invention comporte une étape supplémentaire de filtrage de la requête d'interaction Mb. A cet effet, le système d'accès selon l'invention comporte des moyens de filtrage de la requête d'interaction Mb HTTP. Ces moyens de filtrage, qui peuvent notamment être incorporés dans le serveur proxy 20 (si celui-ci est utilisé) et/ou dans le serveur HTTP du poste utilisateur, vérifient, au cours de cette étape de filtrage, que la requête d'interaction Mb et/ou Mc provient effectivement d'un serveur d'informations personnelles 35 autorisé, sinon, il la rejette. En pratique, cette autorisation peut être préalablement réalisée auprès du fournisseur 25 d'accès au réseau.