FR 2841416 A1 20031226 FR 0207658 A 20020620 Procede de gesti on d' informations de contexte par serveu r intermediaire La presente invention concerne un procede de gestion d'informations de contexte client ou session, liees a la fourniture d'un service, ou contenu, a travers un reseau informatique tel que l'lnternet. Ces informations peuvent en particulier etre memorisees sous la forme de donnees cites mouchards ou >, memorisees en dehors du systeme informatique du fournisseur de contenu et a sa demande. Ces acookies>> peuvent en particulier etre compatibles avec le protocole H1lP de l'lnternet, ou avec des modes de connexion par telephone mobile utilisant un protocole de type Voice Gateway ou VoiceXML ou WAP (pour >) ou SMS (pour >). De plus en plus d'organismes utilisent un systeme informatique pour proposer a distance leurs services a des clients nombreux et varies, a travers un ou plusieurs reseaux informatiques comme l'lnternet par exemple. Du point de vue d es d ifferents intervenants d a ns la gestion d u resea u et d es communications, un tel organisme est egalement appele fournisseur de contenu. Quelle que soit la nature de ce contenu, consultation d'informations, achat ou vente de biens ou services, transmission de fichiers de donnees, il est souvent interessant pour le fournisseur de contenu de conserver des informations sur le contexte de fourniture de son service a chaque client, sur ses precedentes interactions avec ce fournisseur ou avec d'autres, ou sur ses habitudes de comportement dans son utilisation des reseaux informatiques. Du point de vue du serveur fournisseur de contenu, il est difficile ou impossible de reconna^'tre un meme utilisateur d'une session a l'autre, car son adresse IP est susceptible de changer d'une fois a l'autre. Pour reconna^'tre plus facilement cheque client, et eviter de stocker sur le systeme informatique du serveur du site de telles informations de contexte relatives a chaque client, les logiciels utilises pour realiser un serveur de fourniture de contenu a de nombreux clients ont souvent la capacite d'envoyer au systeme informatique de chacun de ces clients un certain nombre de donnees de contexte, par exemple des donnees appelees mouchards ou a cookies >>. De plus, au sein d'une meme session avec le meme utilisateur et le meme terminal client, le protocole HTTP ne permet pas non plus de conserver un contexte specifique a cette session applicative entre deux requetes de l'utilisateur. Le meme type de donnees de contexte est alors utilise sous la forme de >, souvent d'une duree de vie particulierement breve, par exemple 15 mn. Cette appellation >, d'origine anglo-saxonne, fait probablement reference au type de biscuits du meme nom, ou certains ingredients vent incorpores sous la forme de petite morceaux. Un acookie>> est une course chane de caracteres memorisee par un serveur HTTP dans un fichier de l'ordinateur client, ou d'une passerelle que le client utilise. Les > vent utilises pour maintenir un contexte correspondent a la session, ou au client, entre un serveur HTTP et un client connecte. Le mecanisme souvent utilise consiste a stocker dans le > un identifiant temporaire, souvent crypte, qui identifie la session applicative et est appele >, ou un identifiant appelle > d'une plus longue duree de vie, par exemple un an, qui identifie le client en lui-meme. D'autres informations permanentes ou temporaires contenues dans ces acookies>> peuvent etre en particulier la date et l'heure de l'acces du client au site du fournisseur, un compteur, une reponse a un questionnaire rempli lors de cette visite, une information personnelle relative au client et recueillie par le serveur du site ou l'un des servours participant a la communication, par exemple une adresse IP ou un numero de serie de processeur identifiant une machine. L'utilisation d'un compteur est une application courante du >. Cheque visite a une page web incremente la valeur d'un > lie a cette page. En associant ce compteur a la date et l'heure de visite, il est possible de mesurer la frequence des visites et d'en deduire les habitudes de consultation. Ces >, ou donnees de contexte, vent memorises dans le systeme informatique du client, a la demande du systeme du fournisseur et par le logiciel de navigation utilise par ce client pour consulter le site du fournisseur de contenu, par exemple un site web utilisant le protocole HTTP (pour a Hyper Text Transfer Protocol >>). Ces donnees de contexte vent stockees sans intervention de l'utilisateur sur le systeme client, et vent automatiquement retransmises au site du meme fournisseur de contenu ou d'un autre, lors d'une consultation ou d'une connexion ulterieure. De telles donnees de contexte peuvent etre utilisees par exemple pour tenir a jour un maximum de depenses autorisees a un client pour un meme site marchand ou un meme groupe de sites marchands, pour presenter au client des bannieres publicitaires choisies en fonction d es sites qu 'il a visites preced emment, ou pou r ten ir le compte d u nombre de visiteurs differents consultant un site determine en identifiant chacun de ces visiteurs. De telles donnees ne peuvent toutefois pas toujours permettre de retrouver le contexte accompagnant chaque client, en particulier lorsqu'il change d'ordinateur d'une consultation a l'autre, par exemple en passant d'un ordinateur de bureau a un ordinateur portable. En effet, meme s'il fournit des informations communes, comme un meme nom d'identification, la connexion d'un meme utilisateur client par deux ordinateurs differents ne retrouvera pas des donnees de contexte communes aupres du systeme d'un fournisseur de contenu en se basant sur le seul systeme des > selon le protocole HTTP. Un but de ['invention est de permettre a un tel systeme informatique fournisseur de contenu de retrouver des donnees de contexte, par exemple des > de session ou des acookies>> clients, correspondent a un utilisateur client determine ou a une session determinee, sans avoir a en gerer la memorisation dans le systeme du fournisseur de contenu et y compris lorsque cet utilisateur client utilise plusieurs systemes informatiques differents ou plusieurs configurations logicielles differentes pour acceder au service de ce fournisseur. De plus, des services ou contenus de plus en plus nombreux vent ou seront accessibles par l'intermediaire de reseaux ou de terminaux possedant la capacite de traitement de do n nees nu meriq u es ou informatiq u es, et acced ant a un meme systeme informatique fournisseur de contenu, mais fonctionnant selon des normes differentes ou utilisant des interfaces distinctes avec l'utilisateur. Ainsi, le site Internet d'un meme serveur fournisseur de contenu peut par exemple etre accessible a la fois par un micro-ordinateur classique de type PC ou Macintosh communiquant avec l'lnternet sous HTTP par le protocole TCP/IP, et a la fois par un telephone cellulaire se connectant sur l'lnternet, mais qui est incapable de memoriser ce type de donnees de contexte. Cette connexion peut se faire par exemple par le protocole WAP a travers une passerelle WAP Gateway par un protocole UDP lorsque l'on utilise la pile protocolaire WSP, ou TCP/IP pour le protocole WAP 2.0, ou meme en communiquant par des messages sous formes de caracteres emis au format SMS. Un tel site Internet peut egalement etre accessible depuis un telephone filaire ou cellulaire, par des commandes vocales reconnues sous forme de commandes codifiees dans le langage VoiceXML et transmises sous forme TCP/IP ou HTTP jusqu'au fournisseur de contenu, par une passerelle de type > reliant le reseau telephonique et l'lnternet. D'autres types de terminaux, par exemple des organiseurs personnels de type PDA (pour a Personnel Digital Assistant) comme le > (marque deposee), peuvent ou pourront se connecter au reseau Internet sans etre compatibles avec les requetes de memorisation de donnees de contexte utilisees par un fournisseur de contenu determine. De meme, certains types de terminaux peuvent communiquer avec un meme systeme fournisseur de contenu selon plusieurs modes differents, d'une session de communication ou au sein d'une meme session, par exemple par commandes VoiceXML pour certaines interactions et par le protocole WAP ou par messages SMS pour d'autres interactions. Un autre but de ['invention est alors de permettre a un tel systeme informatique fournisseur de contenu de retrouver des donnees de contexte correspondent a un utilisateur client determine, sans avoir a en gerer la memorisation dans le systeme du fournisseur de contenu et y compris lorsque cet utilisateur client utilise plusieurs terminaux dont au moins un fonctionne selon un mode ne permettant pas la memorisation de telles donnees de contexte au sein de certains de ces terminaux, ou lorsque cet utilisateur client utilise un ou plusieurs terminaux communiquant avec le systeme fournisseur de contenu selon au moins un mode ne permettant pas la memorisation de telles donnees de contexte de fa,con compatible avec les logiciels utilises par le systeme fournisseur de contenu, ou lorsque cet utilisateur client utilise un ou plusieurs terminaux communiquant avec le systeme fournisseur de contenu selon plusieurs modes differents n'assurant pas la continuite de la gestion des donnees de contexte associees aux parties de session effectuees sous des modes differents. Un ou plusieurs de ces buts vent atteints par un procede de gestion de donnees de contexte representant des informations soit specifiques a une session de fourniture de contenu par communication informatique, a travers un reseau informatique, entre un dispositif de traitement de donnees numeriques, dit terminal client, et un systeme informatique fournisseur de contenu, soit specifiques a l'utilisateur audit terminal client, soit specifiques a une combinaison de ces elements, ces donnees de contexte etant memorisees en dehors du systeme informatique fournisseur de contenu et a la demande audit systeme fournisseur, caracterise en ce qu'il comporte au moins une etape de memorisation de ces donnees de contexte dans des moyens de memorisation par un ou plusieurs agents informatiques, dits proxy de contexte, dans des moyens de memorisation independents du terminal client et accessibles depuis au moins un systeme informatique ou electronique gerant le reseau informatique. Selon une particularite, le procede comporte en outre au moins une operation d'acces du terminal client au systeme fournisseur de contenu par envoi de donnees representant une requete d'acces, cette operation d'acces comprenant les etapes suivantes: - reception, par au moins un proxy de contexte, de donnees associees a une requete d'acces au systeme fournisseur de contenu de la part du terminal client, ces donnees comprenant au moins une identification fournisseur et une identification client; - test par le proxy de contexte de ['existence ou non de donnees de contexte, memorisees dans des moyens de memorisation independents du terminal client et du systeme fournisseur, ces donnees de contexte correspondent a cette identification fournisseur et a cette identiflcation client; - lecture de ces donnees de contexte, et eventuellement modification de ces donnees de contexte en fonction des informations re,cues correspondent a la requete d'acces; - transmission, au systeme fournisseur de contenu, de tout ou partie des donnees de contexte lues ou d'une version de la requete d'acces modifiee en fonction desdites donnees de contexte. Selon une particularite, le procede comporte au moins une operation de reponse du systeme fournisseur de contenu au terminal client par envoi de donnees representant une reponse, cette operation de reponse comprenant les etapes suivantes: - reception, par au moins un agent proxy de contexte, de donnees associees a une reponse du systeme fournisseur de contenu au terminal client, cette reponse comprenant au moins une demande de memorisation de donnees de contexte devant etre memorisees a l'exterieur audit systeme fournisseur de contenu et a sa demande, lesdites donnees representant au moins une identification fournisseur, et une identification client; - memorisation de donnees de contexte, par le proxy de contexte, dans des moyens de memorisation independents du terminal client et du systeme fournisseur de contenu, ces donnees de contexte representant au moins cette identiflcation fournisseur, cette identification client, et des informations associees a cette reponse. Selon une particularite, I'operation de reponse du systeme fournisseur de contenu au terminal client comprend en outre une etape de demande au terminal client d'une autorisation de memoriser des donnees de contexte. Selon une particularite, le procede comprend au moins une etape de communication ou un agent proxy de contexte communique, directement ou indirectement, d'une part avec le systeme fournisseur de contenu par l'intermediaire du reseau informatique, et d'autre part avec le terminal client ou avec une passerelle de mode permettant la communication du reseau informatique avec ce terminal client selon un mode de communication determine different de celui utilise par le reseau informatique. Selon une particularite, le procede comprend au moins une etape de communication ou un premier agent proxy de contexte communique d'une part avec une premiere passerelle de mode permettant la communication avec ce terminal client selon un premier mode de communication determine, et d'autre part avec un deuxieme agent proxy de contexte communiquant avec ledit terminal client, ce deuxieme agent proxy de contexte communiquant avec ce terminal client soit par le reseau informatique soit par une deuxieme passerelle de mode permettant la communication du reseau avec ce terminal client selon un deuxieme mode de communication determine. Selon une particularite, la session de fourniture de contenu par communication informatique comprend une premiere partie de session, realisee par une communication selon le premier mode de communication, combinee avec une deuxieme partie de session, realisee par une communication selon le deuxieme mode de communication, le procede comprenant au moins une etape de memorisation ou de lecture de donnees de contexte representant des informations utilisables par ['agent proxy de contexte ou par le systeme informatique fournisseur de contenu pour associer ces deux parties de session. Selon une particularite, au moins une etape de communication entre le systeme informatique fournisseur de contenu et ['agent proxy de contexte se fait par au moins un protocole compatible avec le protocole TCP/IP ou le protocole HTTP. Selon une particularite, le terminal client comprend un terminal numerique ou un telephone cellulaire, au moins une etape de communication entre le terminal client et le reseau se faisant par liaison sans fil selon la norme GSM, ou la norme DCS, ou la norme GPRS, ou la norme Airport, ou la norme Bluetooth, ou la norme ISO 802.11 (marques deposees), ou une variante ou evolution de ces normes. Selon une particularite, le terminal client comprend un terminal numerique ou un telephone cellulaire ou filaire, au moins une etape de communication entre le terminal client et le reseau se faisant un protocole compatible avec le protocole WAP, ou un protocole utilisant le langage VoiceXML, ou une variante ou evolution de ces protocoles. Selon une particularite, le reseau permet la communication informatique entre le systeme fournisseur de contenu et le terminal client en utilisant le reseau Internet ou un reseau de type intranet. Selon une particularite, les donnees de contexte emises ou re,cues par le systeme informatique fournisseur de contenu vent organisees selon un format compatible avec les > definis par le protocole HTTP. Pour atteindre ces objectifs, I'invention propose egalement un systeme de gestion de donnees de contexte representant des informations, soit speciflques a une session de fourniture de contenu par communication informatique, a travers un reseau informatique, entre un dispositif de traitement de donnees numeriques, dit terminal client, et un systeme informatique fournisseur de contenu, soit specifiques a l'utilisateur audit terminal client, soit specifiques a une combinaison de ces elements, ces donnees de contexte etant memorisees en dehors du systeme informatique fournisseur de contenu et a la demande audit systeme fournisseur, caracterise en ce qu'il comprend au moins un agent logiciel, dit proxy de contexte, execute par des moyens de calcul et communiquant avec le reseau informatique, ce proxy de contexte memorisant ces donnees de contexte dans des moyens de memorisation independents du terminal client. Selon une particularite, le proxy de contexte comprend d'une part des moyens de fire et d'analyser des donnees representant une reponse du systeme fournisseur au terminal client au sein d'une telle session et comportant des donnees de contexte que le systeme fournisseur demande au terminal client de memoriser, et d'autre part des moyens d'identifler ce systeme fournisseur, des moyens d'identifier ce terminal client ou l'utilisateur de ce terminal client, ainsi que des moyens de memoriser tout ou partie de ces donnees de contexte en association avec ['identification de ce systeme fournisseur, ou de ce terminal client, ou de l'utilisateur de ce terminal client. S elon u ne pa rticu larite, le proxy de contexte co m prend d es moyens de fire et d'analyser des donnees representant une requete d'acces du terminal client au systeme fournisseur au sein d'une telle session, des moyens d'identifier ce systeme fournisseur, des moyens d'identifier ce terminal client ou l'utilisateur de ce terminal client, ainsi que des moyens de completer ou de modifier les donnees de cette requete d'acces en fonction de donnees de contexte precedemment memorisees par lui et en rapport avec ce systeme fournisseur et ce terminal client ou l'utilisateur de ce terminal client. Selon une particularite, le systeme de gestion de donnees de contexte comprend des moyens d'interposition du proxy de contexte entre le terminal client et l'adresse ou ['identification par laquelle il cherche a entrer en communication avec le systeme fournisseur, ou des moyens de redirection du terminal client depuis cette meme adresse vers une adresse conduisant au proxy de contexte, ces moyens d'interposition ou de redirection permettant au proxy de contexte de recevoir en lieu et place du systeme fournisseur tout ou partie des donnees envoyees par le terminal client audit systeme fournisseur de contenu. Selon une particularite, le systeme fournisseur de contenu est accessible, depuis le reseau informatique, sous la forme d'un site au standard ? et communique avec le proxy de contexte selon le protocole TCP/IP ou HTTP. Selon une particularite, le reseau informatique comprend une ou plusieurs parties utilisant le reseau Internet ou un reseau Intranet pour permettre la communication informatique entre le proxy de contexte, le terminal client, et le systeme fournisseur, ou entre deux de ces elements. Selon une particularite, le terminal client communique avec le reseau informatique a travers au moins un systeme informatique, dit passerelle de mode, assurant le passage de donnees informatiques entre d'une part le reseau informatique et d'autre part un deuxieme reseau permettant le transfert de donnees numeriques sous une forme non directement compatible avec le reseau informatique ou avec le systeme fournisseur de contenu. Selon une particularite, au moins une passerelle de mode permet la communication entre d'une part le reseau informatique et d'autre part un reseau de telephonic filaire, ou un reseau de telephonic cellulaire GSM ou DCS ou GPRS, ou un reseau de communication selon le standard Bluetooth ou le standard Airport ou la norme ISO 802.11 (marques deposees). Selon une particularite, le systeme comprend une pluralite d'agents proxy de contexte communiquant entre eux, ou avec le systeme fournisseur de contenu, ou les deux, a travers le reseau informatique, au moins un de ces proxy de contexte etant integre dans une passerelle assurant la transformation entre plusieurs protocoles de communication ou entre plusieurs modes de transmission. L'invention, avec ses caracteristiques et avantages, ressortira plus clairement a la lecture de la description faite en reference aux dessins annexes dans lesquels: - la figure 1 represente un schema symbolique d'un systeme selon ['invention utilisant un procede selon ['invention, dans un mode de realisation comportant un proxy de contexte intermediaire entre le fournisseur et plusieurs reseaux d'acces ou passerelles de mode; - la figure 2 represente un schema symbolique d'un systeme selon ['invention utilisant un procede selon ['invention, dans un mode de realisation comportant plusieurs proxy de contexte, dont certains integres a une passerelle de mode; - la figure 3 represente un organigramme d'un mode de realisation du procede selon ['invention dans le cas ou un terminal client emet une requete d'acces a un fournisseur de contenu; - la figure 4 represente un organigramme d'un mode de realisation du procede selon ['invention dans le cas ou un fournisseur de contenu emet une reponse vers un terminal client. Avant d'aborder la description de ['invention, il est necessaire de preciser les notions suivantes. On appellera agent logiciel un composant logiciel ayant la capacite de reagir a des interactions avec d'autres agents logiciels ou avec des evenements logiciels ou materiels. II doit etre evident que le mode d'execution ou de memorisation d'un agent logiciel determine peut varier au sein d'un ou plusieurs systemes informatiques, tent que leur organisation ne contredit pas le fonctionnement du procede ici decrit. Dans un mode de realisation represente en figures 1 et 2, un organisme ou prestataire fournisseur de contenu utilise un systeme (2) informatique fournisseur de contenu pour proposer un acces a un nombre important et variable d'utilisateurs (3) utilisant des terminaux (31 a 35) clients, par communication informatique a travers un reseau (1) informatique. Ces terminaux clients peuvent etre par exemple des ordinateurs (31, 32), munis de logiciels de navigation, par exemple compatibles avec les langages HTML ou XML, et communiquant avec le reseau Internet (10) ou un reseau de type intranet, par exemple de fa,con classique en utilisant les protocoles TCP/IP et HTTP pour acceder a des sites web, c'est-a-dire consultables selon le standard a W3 >> ou > (pour Web >>). Au sein de la presente description, le reseau (1) informatique sera mentionne comme unique, mais il est evident que ce reseau peut comprendre plusieurs parties d'architectures differentes ou variables. La communication entre deux systemes informatiques de ce reseau (1) peut comprendre I'utilisation du reseau Internet sur une ou plusieurs parties de ce reseau. Les utilisateurs peuvent par exemple se connecter au site (2) du fournisseur de contenu par le reseau Internet (10), eventuellement par l'intermediaire d'un reseau local eVou d'une passerelle locale. Certaines fonctions decrites ici comme relevant du systeme client, comme les Kcookies>>, peuvent alors etre realisees au niveau de ce reseau local ou de cette passerelle. Ce reseau (1) informatique peut egalement utiliser le reseau Internet pour communiquer entre le systeme (2) fournisseur de contenu et le proxy (4) de contexte, ou entre une passerelle (51, 52, 53) et le proxy (4) de contexte ou le systeme (2) fournisseur de contenu. D'autres types de connexions peuvent egalement etre incluses dans ce reseau (1), comme des lignes specialisees ou des communications X25, du moment qu'elles permettent la communication entre les differents elements de ce reseau (1) selon les meme protocoles. De fa,con courante, un meme utilisateur (3) peut utiliser alternativement, voire en meme temps, plusieurs ordinateurs differents ou plusieurs logiciels differents pour se connecter au site (2) d'un meme fournisseur de contenu. II peut par exemple utiliser d'une part un ordinateur (31) de bureau et d'autre part un ordinateur (32) portable ou de voyage. Le procede selon ['invention comprend l'utilisation d'un agent (4) log iciel i ntermed ia ire, d it proxy de contexte, q u i gere en tout ou partie des donnees de contexte relatives a l'utilisateur (3), ou aux differentes sessions qu'il effectue a ['aide des differents systemes (31, 32) informatiques. Cet agent proxy (4) de contexte peut jouer ce role d'intermediaire de differentes fa,cons selon les applications de ['invention. Ce role peut etre realise par exemple par interposition entre systeme client et systeme fournisseur, en gerant l'adresse URL (pour >) d'acces au site du systeme (2) fournisseur. Ce role peut egalement etre realise par une redirection depuis un systeme gerant l'adresse URL du site du fournisseur de contenu. Par ailleurs, selon les applications, le proxy de contexte peut avoir a gerer et transmettre la totalite des donnees echangees au cours d'une session entre systemes clients et fournisseurs, ou n'avoir a traiter qu'une partie de ces donnees, et en particulier les donnees de contexte en tout ou partie. Cet agent proxy de contexte peut bien sOr etre mis en ceuvre en differentes regions du reseau (1) informatique reliant les terminaux clients et le ou les systemes (2) utilises par le fournisseur de contenu. Si plusieurs terminaux clients vent utilises par un utilisateur tout en passant par l'lnternet, ce proxy de contexte peut par exemple etre mis en oeuvre sur un serveur du fournisseur d'acces Internet (FAI), chez un prestataire specialise dans l'hebergement de site de fournisseurs de contenu ou effectuant des prestations pour de tels fournisseurs de contenu, ou directement dans le systeme (2) informatique du fournisseur de contenu. Dans d'autres variantes non representees, le reseau (1) informatique dans son ensemble peut egalement presenter d'autres configurations ou topographies differentes voire heterogenes. II peut ainsi etre constitue en tout ou partie de reseaux locaux (LAN), regionaux (MAN) etendus (WAN), ou integrer une ou plusieurs parties fonctionnant sous la forme de reseaux de type intranet. Ainsi qu'illustre en figure 1, le reseau (1) informatique peut egalement permettre un acces au systeme (2) fournisseur de contenu depuis un terminal (33, 34, 35) client ayant un mode de fonctionnement qui n'est pas directement compatible avec ce systeme (2) fournisseur de contenu ou avec le reseau (1), ainsi que decrit plus loin. Cet acces est rendu possible par une communication du reseau (1) avec un tel terminal a travers un systeme dit passerelle (51, 52, 53) de mode, le fournisseur etant lui meme relic audit reseau (1). Cette passerelle de mode prend alors en charge la transformation de protocole necessaire pour que les interactions du point de vue du fournisseur se fassent en HTTP. Une telle passerelle de mode peut communiquer directement avec le terminal client, ou communiquer avec un autre reseau permettant cette communication, ainsi qu'illustre en figure2. De telles passerelles existent ou existeront de plus en plus, et peuvent etre par exemple une passerelle (52) WAP permettant la communication entre le reseau (1) informatique et un telephonefilaire (35), par communication a travers un Reseau Telephonique Commute, ou un telephone (33) cellulaire a la norme GSM ou DCS par communication a travers un reseau de telephonic cellulaire. Une telle passerelle de mode peut egalement etre une passerelle (51) comprenant une borne de type K Airport>> permettant la communication(510) sans fil d'un assistant (34) personnel ou d'un ordinateur (32) portable tel que le Macintosh I Book (marque deposee) avec l'lnternet(10) ou avecun reseau local. Des passerelles permettant la communication d'un ordinateur portable, ou d'un assistant personnel, peuvent egalement utiliser des bornes ou des mini reseaux locaux a la norme >, ou a la norme ISO 802.11, pour un peripherique de liaison par cable (320) , ou par infrarouge, ou par radio, ce peripherique etant lui-meme relic a un ordinateur communiquant avec le reseau (1). Avec ['evolution des normes de telephonic cellulaires, en particulier avec l'arrivee des normes GPRS et UMTS, de telles passerelles peuvent egalement permettre d'echanger des commandes ou des donnees sous une forme compatible avec un tel systeme (2) fournisseur de contenu. Une passerelle entre le reseau (1) et un reseau de telephonic cellulaire peut en particulier comprendre des ressources logicielles et materielles lui permettant d 'inte rpreter des interactions vocales sous la forme de comma ndes log iciel les, ou de restituer des informations de type vocal a partir d'informations logicielles. Le langage > est un exemple de langage utilisable par une telle passerelle (53), cite > ou Passerelle Vocale, pour communiquer avec le reseau (1), en envoyant automatiquement des commandes informatiques, similaires aux commandes XML, a partir d'instructions vocales rec,ues depuis un telephone. Dans une variante non representee, au sein du reseau (1), de telles passerel les de mod es peuvent bien sur egalement co m mu n iqu e r avec le proxy de contexte et le systeme fournisseur de contenu par l'intermediaire du reseau Internet ou d'un reseau de type Intranet. Dans une variante representee en figure 2, les fonctions du proxy de contexte vent assurees par plusieurs agents logiciels proxys (4, 42, 43) de contexte, repartis dans le reseau (1), et dont certains (42, 43) peuvent etre associes ou integres a des passerelles (52, respectivement 53) de mode. Une ou plusieurs passerelles assurent alors, en plus de la transformation de protocoles, le role de memorisation et de retransmission des >. Dans une option de cette variante, ces proxy (4, 42, 43) de contexte repartis dans le reseau (1) pourront egalement etre prevus pour comporter des moyens (49) de communiquer entre eux par l'intermediaire du reseau (1) , permettant ainsi une mise en commun de leurs donnees de contexte, ou > de session, qui puisse etre transparente vis-a-vis du fournisseur (2) de contenu. Dans le mode de realisation represente en figure 1, les communications entre le terminal client et le systeme (2) fournisseur de contenu passent par ['agent (4) proxy de contexte. Ce transit est obtenu par exemple en faisant aboutir au proxy (4) de contexte l'adresse URL correspondent au systeme (2) fournisseur de contenu et au site web qu'il gere. Cette adresse URL peut egalement aboutir au systeme (2) fournisseur, celui-ci red irig ea nt a lors les demandes d 'acces de term inal clients vers u ne ad resse URL aboutissant au proxy de contexte. Ainsi qu'illustre en figure 3, une requete (300) d'acces HTTP au systeme (2) fournisseur de contenu venant du terminal (30) client est re,cue (61) par le proxy (4) de contexte. Cette requete comprend des donnees (304) de requete associees a une ou plusieurs en-fetes contenant des donnees representant differentes informations complementaires. Ces informations vent en particulier une identification (301) du fournisseur a qui s'adresse la requete d'acces, une identification (302) du client, et d'eventuelles donnees de contextes ou un Kcookie>> (303) memorises au cours d'une session ou partie de session precedente par le terminal (30) client. Selon les applications, ['identification (301) fournisseur peut comporter l'adresse IP ou URL d'acces au systeme (2) fournisseur. Selon les modes de realisation et selon les modes d'acces, I'identification (302) du terminal (30) client peut prendre differentes formes, et etre plus ou moins precise ou permanente. ll peut s'agir d'une adresse IP identifiant le terminal client au sein du reseau TCP/IP et transmis par le fournisseur d'acces Internet du client ou par une passerelle intermediaire. II peut s'agir d'un nom saisi par l'utilisateur pour acceder a un compte ou a un service, ou d'un numero de serie d'abonnement, de terminal, de cle de securite, de carte a puce, ou de logiciel. ll peut s'agir d'un numero d'appelant provenant d'un reseau telephonique filaire ou cellulaire, par exemple un numero MSISDN ou identifiant transmis par l'intermediaire d'un element du reseau telephonique ou d'une passerelle (51, 52, 53) de mode. Le proxy (4) de contexte comprend ou utilise des moyens (40, 402, 403) de detection de cette identification (302) client, prevus pour detecter ou recevoir un ou plusieurs de ces identifiants et eventuellement les combiner entre eux pour obtenir ladite identification (302) client A reception de cette requete d'acces, le proxy de contexte effectue une etape (62) de test des informations contenues ou associees a cette requete pour savoir si le terminal client fournit un K cookie >> (303), c'est-a-dire des donnees de contexte, utilisable par ce fournisseur ou en rapport avec ce fournisseur. Cette etape comprend un test de ['identification (302) client eVou de ['identification (301) fournisseur Si la requete d'acces ne comporte pas de donnees de contexte, ou des donnees ne correspondent pas a des parametres determines, le proxy de contexte effectue une etape (63) de test de ['identification (301) fournisseur et de ['identification (302) de cette requete (300) d'acces. En comparant ces identifications (301, 302) et les differentes donnees (40) de contexte auxquelles il a acces, le proxy (4) de contexte determine alors s'il dispose deja, pour ce terminal (30) client ou pour l'utilisateur (3) de ce terminal client, de donnees de contexte utilisables par ce fournisseur (2) ou en rapport avec ce fournisseur. Si de telles donnees (40) de contexte vent presentes, elles vent lues au cours d'une etape (64) par le proxy de contexte, qui s'en sert pour enrichir le contenu de la requete (300) d'acces re,cue du terminal (30) client. Selon les applications, cet enrichissement peut se faire en ajoutant les donnees lues a la requete d'acces, ou en modifiant tout ou partie de cette requete en fonction de ces memes don nees de contexte. Da ns le mode de real isation decrit ici, cet enrichissement comprend en particulier ['insertion de ces donnees (40) de contexte dans l'en-tete de la requete (300) d'acces, comme s'il s'agissait d'un > (303) re, cu directement depuis le terminal (30) client. Dans une variante (non representee) appliquee au mecanisme d'URL dynamique cite plus loin, cet enrichissement peut comprendre la modification de l'adresse demandee, en y ajoutant les donnees (301) d'identification fournisseur ou les don nees (302) d'identification d u terminal ou d u client, a partir de ces don nees (40) de contexte retrouvees par le proxy de contexte. Selon les applications, le proxy de contexte peut egalement modifier, lors d'une etape (66), les donnees (40) de contexte memorisees, par exemple pour y enregistrer la date de cette requete d'acces ou mettre a jour la duree de vie memorisee pour ce >. Le proxy de contexte va alors transmettre la requete (300) d'acces au systeme (2) fournisseur de contenu, enrichie a partir de donnees (40) de contexte fournies par lui le cas echeant. Si le terminal (30) client se connecte au systeme (2) fournisseur sans domaine commercial ou statistique. Ainsi qu'illustre en figure 3, une reponse (200) du systeme (2) fournisseur de contenu au terminal (30) client est re,cue (71) par le proxy (4) de contexte au cours d'une session de communication. Cette reponse comprend des donnees (204) de reponse associees a une ou plusieurs en-fetes contenant des donnees representant differentes informations complementaires. Ces informations vent en particulier une identification (201) du fournisseur de qui emane la reponse, une identification (202) du client a qui stadresse la reponse, et d' eventuelles don nees de contexte ou u n > (203) q ue le systeme (2) fournisseur souhaite faire memoriser, ou positionner, au sujet de cette session ou de l'utilisateur (30) de ce terminal (30) client. Selon les applications, I'identification (201) fournisseur peut comprendre l'adresse IP ou URL du systeme (2) fournisseur, ou un identifiant d'abonnement de ce fournisseur ou d'un groupe de fournisseurs differents pouvant etre concernes par cette reponse ou cette session ou les cookies qu'elles positionnent. Selon les modes de real isation et selon les mod es d'acces, I'identification (202) du terminal (30) client peut prendre differentes formes, et etre plus ou moins precise ou permanente. II peut stagir d'une adresse IP identifiant le terminal client au sein du reseau TCP/IP et transmis par le fournisseur d'acces Internet du client ou par une passerelle intermediaire. II peut s'agir d'un nom saisi par l'utilisateur pour acceder a un compte ou a un service, ou d'un numero de serie d'abonnement, de terminal, de cle de securite, de carte a puce, ou de logiciel. ll peut stagir d'un numero d'appelant provenant d'un reseau telephonique filaire ou cellulaire, par exemple un numero MSISDN ou un identifiant transmis par l'intermediaire d'un element du reseau telephonique ou d'une passerelle (51, 52, 53) de mode. Le proxy (4) de contexte va alors effectuer une etape (72) de test des informations contenues ou associees a cette reponse, pour savoir si cette reponse demande la memorisation, ou le positionnement, d'un > (203) dans le terminal (30) client, en particulier selon le standard des Kcookies>> utilises dans les protocoles WWW et HTTP. Si cette reponse comporte une demande (203) de memorisation de >, le proxy de contexte va alors effectuer une etape de memorisation (75) de ce acookie>> (203), sous la forme de donnees (40) de contexte, dans des moyens de memorisation independent du terminal (30) cl ient, par exemple d ans les moyens de memo risation d u systeme info rmatique qui execute cet agent (4) proxy de contexte. Ainsi, quel que soit le devenir du terminal (30) utilise par le client accedant au fournisseur de contenu, les donnees (203) de contexte envoyees par le systeme (2) fournisseur pourront etre conservees et retrouvees lors d'une prochaine requete (300) d'acces telle que decrite plus haut. Selon une option permettant de laisser a l'utilisateur du terminal client un contrBle des informations memorisees sur lui, le proxy de contexte effectue une etape (73) de demande au terminal (30) client s'il est programme pour autoriser la memorisation de donnees de contexte, de fa, con generale ou dans le cas present. Cette etape (73) de demande d'autorisation peut se faire par exemple par le meme canal utilise pour echanger les requetes et reponses avec ce terminal client. En fonction de la reponse du terminal (30) client, le proxy (4) de contexte va alors effectuer ou non une etape (75) de memorisation du acookie>> (203) demande par le fournisseur, sous la forme de donnees (404) de contexte stockee dans des moyens de memorisation independents du terminal (30) client et du systeme (2) fournisseur. Le proxy de contexte pourra ensuite transmettre au terminal (30) client les donnees representant la reponse (200) du systeme (2) fournisseur de contenu. Par rapport au procede connu de memorisation de > dans le terminal client, il est ainsi possible de memoriser des donnees de contexte de fa,con transparente pour le fournisseur (2) de contenu, meme si le terminal (30) client est d'un type non compatible avec le procede classique ou d'un type ne permettant pas la memorisation de donnees. Dans le cas ou l'acces au systeme (2) fournisseur de contenu se fait par un terminal client disposant de plusieurs modes (520, 530, 320) de communication avec le reseau (1), le procede selon ['invention permet egalement de memoriser, puis d'associer entre elles des donnees de contexte, ou cookie>> de session, memorisees pour chacun de ces differents modes (520, 530, 320). Si une meme session de communication entre l'utilisateur client et le systeme (2) fournisseur de contenu comprend l'utilisation alternative ou simultanee de plusieurs modes de communication en plusieurs parties de session, avec un meme terminal (33) client, ou avec plusieurs terminaux (33, 32, 31) clients, le procede selon ['invention permet alors d'associer ces differentes parties de session, par exemple pour reconstituer ['unite d'une session multimodale. Un exemple de session multimodale peut etre l'acces a un service, sur le site du fournisseur de contenu, en utilisant un telephone (33) portable cell u laire, a la fois par d es acces selon le mode WAP et par des acces selo n le mode VoiceXML. Pendant une partie de session ou un utilisateur (3) navigue dans le service en utilisant son telephone selon le mode d'acces WAP a travers la passerelle (52) WAP, le systeme (2) fournisseur emet un > que le proxy (4) de contexte memorise > dans ses moyens de memorisation. Apres certaines actions dans le service, le fournisseur de contenu propose a l'utilisateur de continuer sa navigation grace a une interface vocale, dans un mode de type VoiceXML. Pour cela, le service propose par exemple a l'utilisateur une commande de type WAP intitulee >, qui va declencher l'appel de la passerelle (53) VoiceXML. Lorsque la passerelle VoiceXML emet une requete HTTP vers le systeme (2) fournisseur de contenu, cette requete passe par le proxy(4) de contexte. En comparant les identifiants clients re,cus par ses moyens (40) de detection depuis les passerelles WAP puis VoiceXML, avec des donnees deja memorisees, par exemple dans un precedent > de session, le proxy de contexte constate que ces identifiants correspondent a un meme telephone (33) et s'adressent au meme fournisseur. II va alors enrichir la requete provenant de la passerelle VoiceXML avec le > de session qu'il avait precedemment memorise lors de la partie WAP de la session. La requete de type VoiceXML peut alors etre traitee par le systeme fournisseur avec le benefice du contexte de session genere lors de l'acces WAP precedent. Lorsque l'utilisateur termine son acces vocal, I'acces WAP peut reprendre, lorsque le telephone detecte un evenement de type WAP intitule aWTA fin d'appel >> ou lorsque l'utilisateur valide un lien ou un bouton correspondent sur la page WAP precedemment affichee. De la meme fa,con, lorsque la session revient en mode WAP, le proxy de contexte effectue ['association avec la partie de session vocale, en identifiant l'utilisateur et en retrouvant le > de session precedemment memorise lors d'une requete VoiceXML. La suite de la session beneficie alors du contexte memorise et tenu a jour a la fois pendant la premiere partie de session WAP et pendant la partie de session VoiceXML. Le procede permet ainsi de maintenir une continuite du contexte applicatif au cours d'une session utilisant ces deux types d'acces. De telles sessions multimodales peuvent ainsi etre reunifiees, par exemple pour un traitement plus precis ou plus sur, dans des applications variees. II peut s'agir par exemple d'utiliser un telephone cellulaire pour effectuer certaines interactions trop complexes pour un clavier telephonique, par exemple indiquer une destination a un systeme de gestion d'itineraire, ces interactions passant alors par une passerelle (53) vocale. Les informations devant etre permanentes au cours d'une meme session multimodale peuvent alors etre transmises par une passerelle WAP ou par messages SMS, par exemple pour afficher un plan de parcours sur l'ecran du telephone ou de I'assistant personnel. Au sein du reseau (1), I'ensemble des donnees de contexte obtenues par le procede selon ['invention peut etre gere a differents niveaux. Un ou plusieurs proxy de contexte peuvent par exemple gerer ['association des donnees de contexte provenant de differentes parties de session pour reconstituer ltensemble de la session multimodale, de fa,con transparente pour le systeme (2) fournisseur de contenu. Un ou plusieurs proxy de contexte peuvent egalement enrichir ces donnees de contexte en les combinant avec diverges informations provenant de certains elements de gestion du reseau (1) informatique en iui-meme, tels qu'un routeur ou un serveur, par exemple un serveur Radius (marque deposee). De telles informations peuvent etre par exemple une adresse IP utilisee par le protocole TCP/IP pour identifier un nceud au sein du reseau (1), ou un numero d'identifiant de telephone cellulaire ou de la carte SIM qu'il utilise, transmis par exemple par la passerelle de mode. Le procede permet ainsi de restituer au fournisseur la totalite d'une session multimodale, comme s'il s'agissait d'une simple session unique. Le procede selon ['invention permet ainsi la memorisation de > et la lecture de ces acookies>>, de fa,con transparente pour un serveur web constituent alors le systeme (2) fournisseur, en particulier dans le cas d'un acces depuis un telephone (33) portable ou un telephone (35) filaire, ou d'un assistant (34) personnel, depuis plusieurs ordinateurs (31, 32) differents, ou d'une combinaison de tels dispositifs. Dans d'autres variantes (non representees), un systeme fournisseur de contenu utilise un mecanisme d'adresses calculees en fonction du contexte de chaque session, egalement appele > (a partir de URL, pour >). Ce mecanisme comprend, entre autres, le fait d'associer des donnees d'identifications a certaines des adresses communiquees au terminal client pour le guider au cours d'une session tent que liens de navigation au sein du site web du fournisseur de contenu. En choisissant de suivre un lien dont l'adresse lui a ete communiquee par le systeme fournisseur, le terminal client emet alors une requete d'acces contenant des donnees calculees precedemment par le fournisseur en fonction du contexte de cet utilisateur ou de son terminal. Ces donnees peuvent alors etre testees et memorisees par le procede selon ['invention, sous la forme de donnbes (40) de contexte, de la meme fa,con que les > decrits plus haut. II doit etre evident pour les personnel versees dans l'art que la presente invention permet des modes de realisation sous de nombreuses autres formes specifiques sans l'eloigner du domaine d'application de ['invention comme revendique. Par consequent, les presents modes de realisation dolvent etre consideres a titre d/illustration, mais peuvent etre modifies dans le domaine defini par la portee des revendications jointes, et ['invention ne doit pas etre limitee aux details donnes ci-dessus. REVENDICATIONS 1. Procede de gestion de donnees (40) de contexte representant des informations soit specifiques a une session de fourniture de contenu par communication informatique, a travers un reseau (1) informatique, entre un dispositif de traitement de donnees numeriques, dit terminal (30 a 35) client, et un systeme (2) informatique fournisseur de contenu, soit specifiques a l'utilisateur audit terminal client, soit specifiques a une combinaison de ces elements, ces donnees (40) de contexte etant memorisees en dehors du systeme (2) informatique fournisseur de contenu et a la demande audit systeme (2) fournisseur, caracterise en ce qu'il comporte au moins une etape de memorisation de ces donnees de contexte dans des moyens de memorisation par un ou plusieurs agents informatiques, dits proxy (4) de contexte, dans des moyens de memorisation independents du terminal client et accessibles depuis au moins un systeme informatique ou electronique gerant le reseau (1) informatique. 2. Procede selon la revendication 1, caracterise en ce que qu'il comporte en outre au moins une operation d'acces du terminal (30) client au systeme (2) fournisseur de contenu par envoi de donnees representant une requete (300) d'acces, cette operation d'acces comprenant les etapes suivantes: reception (61), par au moins un proxy (4) de contexte, de donnees associees a une requete (200) d'acces au systeme (2) fournisseur de contenu de la part du terminal (30) client, ces donnees comprenant au moins une identification (301) fournisseur et une identification (302) client; test (62, 63) par le proxy (4) de contexte de ['existence ou non de donnees (40) de contexte, memorisees dans des moyens de memorisation independents du terminal (30) client et du systeme (2) fournisseur, ces donnees (40) de contexte correspondent a cette identification (301) fournisseur et a cette identification (302) client; - lecture (64) de ces donnbes (40) de contexte, et eventuellement modification (65) de ces donnees de contexte en fonction des informations re,cues correspondent a la requete d'acces; - transmission (67), au systeme (2) fournisseur de contenu, de tout ou partie des donnees (40) de contexte lues ou d'une version de la requete (300) d'acces modifiee en fonction desdites donnees (40) de contexte. 3. Procede selon la revendication 1 ou 2, caracterise en ce qu'il comporte au moins une operation de reponse du systeme (2) fournisseur de contenu au terminal (30) client par envoi de donnees representant une reponse (200), cette operation de reponse comprenant les etapes suivantes: - reception (71), par au moins un agent proxy(4) de contexte, de donnees associees a une reponse (200) du systeme (2) fournisseur de contenu au terminal (30) client, cette reponse comprenant au moins une demande (203) de memorisation de donnees (40) de contexte, ces donnees de contexte devant etre memorisees a I'exterieur audit systeme fournisseur de contenu et a sa demande,; - memorisation (75) de donnees (40) de contexte, par le proxy (4) de contexte, dans des moyens de memorisation independents du terminal (30) client et du systeme (2) fournisseur de contenu, ces donnees de contexte representant des informations associees a cette reponse (200), ou au terminal (30 a 35) client, ou a l'utilisateur (3) de ce terminal client, ou au systeme (2) fournisseur de contenu. 4. Procede selon la revendication 3, caracterise en ce que la memorisation des donnees (40) de contexte comprend la memorisation d'un identifiant client ou d'un identifiant de session. 5. Procede selon la revendication 3 ou 4, caracterise en ce que I'operation de reponse du systeme (2) fournisseur de contenu au terminal (30) client comprend en outre une etape (73) de demande au terminal client d'une autorisation de memoriser des donnees (40) de contexte. 6. Procede selon l'une des revendications 1 a 5, caracterise en ce qu'il comprend au moins une etape de communication ou un agent (4) proxy de contexte communique, directement ou indirectement, d'une part avec le systeme (2) fournisseur de contenu par l'intermediaire du reseau (1) informatique, et d'autre part avec le terminal (33, 34, 35) client ou avec une passerelle (51, 52, 53) de mode permettant la communication du reseau (1) informatique avec ce terminal client selon un mode de communication (510, 520, 530) determine different de celui utilise par le reseau informatique. 7. Procede selon l'une des revendications 1 a 6, caracterise en ce qu'il comprend au moins une etape de communication ou un premier agent (42) proxy de contexte communique d'une part avec une premiere passerelle (52) de mode permettant la communication avec ce terminal (33) client selon un premier mode (520) de communication determine, et d'autre part avec un deuxieme agent(43) proxy de contexte communiquant avec ledit terminal client, ce deuxieme agent proxy de contexte communiquant avec ce terminal client soit par le reseau (1, 320) informatique soit par une deuxieme passerelle (53) de mode permettant la communication du reseau (1) avec ce terminal client selon un deuxieme mode (530) de communication determine. 8. Procede selon la revendication 7, caracterise en ce que la session de fourniture de contenu par communication informatique comprend une premiere partie de session, realisee par une communication selon le premier mode (520) de communication, combinee avec une deuxieme partie de session, realisee par une communication selon le deuxieme mode (530) de communication, le procede comprenant au moins une etape de memorisation ou de lecture de donnees (40) de contexte representant des informations utilisables par ['agent (4) proxy de contexte ou par le systeme (2) informatique fournisseur de contenu pour associer ces deux parties de session. 9. Procede selon l'une des revendications 1 a 8, caracterise en ce qu'au moins une etape de communication entre le systeme (2) informatique fournisseur de contenu et ['agent proxy (4) de contexte se fait par au moins un protocole compatible avec le protocole TCP/IP ou le protocole HTTP. 10. Procede selon l'une des revendications 1 a 9, caracterise en ce que le terminal client comprend un terminal (34) numerique ou un telephone (33) cellulaire, au moins une etape de communication entre le terminal client et le reseau (1) se faisant par liaison sans fil selon la norme GSM, ou la norme DCS, ou la norme GPRS, ou la norme Airport, ou la norme Bluetooth, ou la norme ISO 802.11 (marques deposees), ou une variante ou evolution de ces normes. 11. Procede selon l'une des revendications 1 a 10, caracterise en ce que le terminal client comprend un terminal (34) numerique ou un telephone (33) cellulaire ou filaire (35), au moins une etape de communication entre le terminal client et le reseau (1) se faisant un protocole compatible avec le protocole WAP, ou un protocole utilisant le langage VoiceXML, ou une variante ou evolution de ces protocoles. 12. Procede selon l'une des revendications 1 a 11, caracterise en ce que le reseau permet la communication informatique entre le systeme (2) fournisseur de contenu et le terminal (30 a 35) client en utilisant le reseau (10) Internet ou un reseau de type intranet. 13. Procede selon l'une des revendications 1 a 12, caracterise en ce que les donnees (203) de contexte emises ou les donnees (303) de contexte re,cues par le systeme informatique fournisseur de contenu vent organisees selon un format compatible avec les > definis par le protocole HTTP. 14. Systeme de gestion de donnees de contexte representant des informations, soit specifiques a une session de fourniture de contenu par communication informatique, a travers un reseau (1) informatique, entre un dispositif de traitement de donnees numeriques, dit terminal (30 a 35) client, et un systeme (2) informatique fournisseur de contenu, soit specifiques a l'utilisateur audit terminal client, soit specifiques a une combinaison de ces elements, ces donnees(40) de contexte etant memorisees en dehors du systeme (2) informatique fournisseur de contenu et a la demande audit systeme (2) fournisseur, caracterise en ce qu'il comprend au moins un agent logiciel, dit proxy (4) de contexte, execute par des moyens de calcul et communiquant avec le reseau (1) informatique, ce proxy (4) de contexte memorisant ces donnees (40) de contexte dans des moyens de memorisation independents du terminal client. 15. Systeme selon la revendication 14, caracterise en ce que le proxy (4) de contexte comprend d'une part des moyens de fire et d'analyser des donnees representant une reponse (200) du systeme fournisseur(2) au terminal (30) client au sein d'une telle session et comportant des donnees (203) de contexte que le systeme fournisseur demande au terminal client de memoriser, et d'autre part des moyens d'identifier ce systeme fournisseur, des moyens d'identifier ce terminal client ou l'utilisateur (3) de ce terminal client, ainsi que des moyens de memoriser tout ou partie de ces donnees (203) de contexte en association avec ['identification de ce systeme fournisseur, ou de ce terminal client, ou de l'utilisateur de ce terminal client. 16. Systeme selon l'une des revendications 14 a 15, caracterise en ce que le proxy (4) de contexte comprend des moyens de fire et d'analyser des donnees representant une requete(300) d'acces du terminal (30) client au systeme fournisseur au sein d'une telle session, des moyens d'identifier ce systeme (2) fournisseur, des moyens (40, 401, 402, 403) d'identifier ce terminal client ou l'utilisateur (3) de ce terminal client, ainsi que des moyens de completer ou de modifier les donnees de cette requete d'acces en fonction de donnees (40) de contexte precedemment memorisees par lui et en rapport avec ce systeme fournisseur et ce terminal client ou l'utilisateur de ce terminal client. 17. Systeme selon l'une des revendications 14 a 16, caracterise en ce que les moyens de completer ou modifier les donnees de la requete d'acces permettent d'incorporer un identifiant de client ou un identifiant temporaire correspondent a la session en cours. 18. Systeme selon l'une des revendications 14 a 17, caracterise en ce q u ' il com prend des moyens d 'interposition d u proxy (4) de contexte entre le terminal client et l'adresse ou ['identification par laquelle il cherche a entrer en communication avec le systdme fournisseur, ou des moyens de redirection du terminal client depuis cette meme adresse vers une adresse conduisant au proxy de contexte, ces moyens d'interposition ou de redirection permettant au proxy de contexte de recevoir en lieu et place du systeme fournisseur tout ou partie des donnees (300) envoyees par le terminal client audit systeme fournisseur de contenu. 19. Systeme selon l'une des revendications 14 a 18, caracterise en que le systeme (2) fournisseur de contenu est accessible, depuis le reseau (1) informatique, sous la forme d'un site au standard ' et communique avec le proxy (4) de contexte selon le protocole TCP/IP ou HTTP. 20. Systeme selon l'une des revendications 14 a 19, caracterise en ce que le reseau (1) informatique comprend une ou plusieurs parties utilisant le reseau Internet(10) ou un reseau Intranet pour permettre la communication informatique entre le proxy (4) de contexte, le terminal (31, 32) client, et le systeme (2) fournisseur, ou entre deux de ces elements. 21. Systeme selon l'une des revendications 14 a 20, caracterise en ce que le terminal (33, 34, 35) client communique avec le reseau (1) informatique a travers au moins un systeme (51, 52, 53) informatique, dit passerelle de mode, assurant le passage de donnees informatiques entre d'une part le reseau (1) informatique et d'autre part un deuxieme (510, 520, 530) reseau permettant le transfert de donnees numeriques sous une forme non directement compatible avec le reseau (1) informatique ou avec le systeme (2) fournisseur de contenu. 22. Systeme selon l'une des revendications 14 a 21, caracterise en ce qu'au moins une passerelle de mode permet la communication entre d'une part le reseau (1) informatique et d'autre part un reseau de telephonic filaire, ou un reseau de telephonic cellulaire GSM ou DCS ou GPRS, ou un reseau de communication selon le standard Bluetooth ou le standard Airport ou la norme ISO802.11 (marquee deposees). 23. Systeme selon l'une des revendications 14 a 22, caracterise en ce qu'il comprend une pluralite d'agents (41, 42, 43) proxy de contexte communiquant entre eux, ou avec le systeme fournisseur de contenu, ou les deux, a travers le reseau informatique, au moins un de ces proxy de contexte etant integre a une passerelle assurant la transformation entre plusieurs