FR 2850771 A1 20040806 FR 0301296 A 20030204 PROCEDE D'ENRICHISSEMENT DU CONTENU D'UNE PAGE NUMERIQUE DONT LE FORMAT PERMET LA CREATION DE LIENS VERS DES OBJETS INFORMATIQUES La présente invention se rapporte au domaine des procédés d'enrichissement du contenu de pages numériques. La présente invention se rapporte plus particulièrement à l'enrichissement du contenu de pages numériques dont le format permet la création de liens vers des objets informatiques. Il peut par exemple s'agir de pages Web ou de pages consultables sur un appareil nomade tel qu'un PDA. La publicité est aujourd'hui présente sur de nombreux sites web. De nombreux procédés permettent de cibler le contenu des bandeaux publicitaires en fonction de l'utilisateur. On connaît déjà plusieurs solutions de l'art antérieur. L'art antérieur connaît déjà par la demande de brevet PCT WO 99/57660 (iWeb Ltd. ) un système et un procédé destinés à fournir un contenu, y compris un contenu d'informations riches à un public particulier d'utilisateurs d'ordinateurs, de préférence conformément aux caractéristiques de ces utilisateurs, de telle façon que le contenu soit exposé de manière contrôlée et soit transféré par une tierce partie dans un système "deux parties", tel que le World Wide Web. Par exemple, plutôt que de transférer le contenu, tel qu'une publicité, en tant que partie d'une page Web sur un site Web éloigné de l'utilisateur de l'ordinateur, l'invention transfère la publicité par l'ISP (prestataire de service Internet) de l'utilisateur, par exemple, sur l'écran de l'ordinateur de l'utilisateur. La publicité ou un autre contenu est ainsi affiché facultativement à l'utilisateur, sans tenir compte du fait que la page Web soit affichée sur l'écran de l'ordinateur de l'utilisateur, d'une manière sensiblement transparente pour l'utilisateur. De cette façon, le contenu est ciblé spécifiquement à l'utilisateur, plutôt que d'être affiché de façon générale sur la page Web ou analogue transférée par des voies "deux parties" telles que des serveurs Web. L'art antérieur connaît également par la demande de brevet américain US 5948061 (Double Click) des méthodes et des dispositifs pour cibler la distribution de publicité à travers un réseau comme l'Internet. Des statistiques sont compilées sur les utilisateurs individuels et les réseaux et l'utilisation des publicités est observée pour permettre un ciblage des utilisateurs individuels par les publicités. En réponse aux requêtes des sites affiliés, un serveur de publicité transmet aux personnes accédant à la page du site une publicité appropriée basée sur le profilage des utilisateurs et des réseaux. L'art antérieur connaît également, par la demande de brevet PCT WO 01/29727 (Adfluence), des procédés de réseau pour la publicité interactive et le marketing direct. Dans un procédé de publicité interactive pour l' Internet, un bandeau est affiché dans l'espace de publicité d'une page Web. Le bandeau permet à l'utilisateur d'effectuer une transaction d'achat ou de visualiser une liste de biens et de services avec des descriptions, ceci sans quitter la page Web. La transaction de l'utilisateur a lieu grâce au bandeau, et ainsi l'utilisateur n'a pas besoin de quitter la page Web pour effectuer un achat. L'espace de publicité et le programme selon l'invention fournissent une apparence personnalisée qui ressemble à la marque de l'annonceur. L'extraction de données est fournie au moyen de l'interaction de l'utilisateur avec l'espace publicitaire, et des bases de données d'information peuvent être constituées dans le but de connaître les profils d'utilisateurs, de réaliser des actions marketing et de mettre en #uvre des analyses statistiques. L'art antérieur connaît aussi, par la demande de brevet américain US 20020111865 (Enliven), un procédé pour suivre les micro-interactions de l'utilisateur dans la publicité sur une page Web. En connexion avec l'affichage de publicité dans les pages Web, une applet est téléchargée vers le navigateur Web de l'utilisateur pour suivre les interactions de l'utilisateur avec la page Web. Les interactions de l'utilisateurs suivies comprennent la position du curseur de la souris, le temps passé sur la page, le temps passé par le curseur sur la publicité, et ainsi de suite. A un moment approprié, comme par exemple lorsque l'affichage de la page Web est terminé, l'applet transmet l'information sur les interactions du client à un serveur distant, le serveur distant étant typiquement contrôlé par un annonceur, ou similaire. Comme résultat, l'annonceur peut suivre la réponse du consommateur aux impressions de publicité sur la page Web sans demander à l'utilisateur de télécharger d'autres pages. Ceci permet aux annonceurs de suivre la réponse de l'utilisateur à des éléments spécifiques de la page Web et d'obtenir de meilleures informations au sujet des centres d'intérêts de l'utilisateur afin de qualifier l'utilisateur avant de présenter la publicité. On connaît également, par la demande de brevet PCT WO 01/44969 (Ad4Ever), un procédé et un système pour présenter une publicité animée sur une page Web. Cette demande de brevet PCT concerne un procédé de présentation d'une publicité animée sur une page Web. Selon ce procédé, un serveur Web obtient une couche de page Web, conçue pour contenir une publicité animée possédant au moins un objet traversant en courant une page Web téléchargée dans un ordinateur client relié au serveur Web, sans à un quelconque moment cacher ou mettre hors service des portions de la page Web se situant à l'extérieur d'une limite des objets. Le serveur Web télécharge alors la couche de la page Web sur l'ordinateur client, aux fins d'affichage du contenu publicitaire animé, associé à ladite page Web. De préférence, la publicité animée est affichée en tant que bref clip animé se rapportant à un produit ou à un service, afin de capter l'attention d'un observateur, et affichant un lien avec une publicité conservée en association avec un serveur Web de publicités, lui-même associé au produit ou service. Ainsi, l'observateur peut obtenir d'autres informations relatives au produit ou service, en cliquant sur le lien. La publicité animée constitue ainsi une annonce-mystère destinée à inciter l'utilisateur à demander une publicité, le lien servant de rappel de la publicité après la fin de l'annonce-mystère. On connaît également, par la demande de brevet PCT WO 99/60504 (Unicast Communications), une technique servant à mettre en place dans un environnement clientserveur en réseau de la publicité répartie par réseau. Selon cette technique, des publicités sont téléchargées à partir d'un serveur de publicité vers un navigateur exécuté à un ordinateur de client, et ultérieurement affichées par ce navigateur de manière interstitielle, en réponse à un clic produit par l'utilisateur. Une étiquette publicitaire HTML est incorporée dans une page web de renvoi. Cette étiquette contient deux éléments. Un élément télécharge effectivement, à partir d'un serveur web de répartition, et instancie continuellement un agent dans le navigateur de client, cet agent téléchargeant des fichiers publicitaires provenant d'un système de gestion publicitaire situé sur un serveur web de publicité tiers, pour une publicité donnée dans la mémoire cache du navigateur, et reproduit ultérieurement ces fichiers de supports par l'intermédiaire du navigateur de manière interstitielle. L'autre élément est une référence du système de gestion publicitaire, qui "dissocie" totalement le contenu publicitaire d'une page web, de sorte qu'une page web ne contient qu'une étiquette publicitaire se référant, via un URL, à un système de gestion publicitaire spécifique. Le système de gestion publicitaire spécifique sélectionne la publicité donnée à télécharger. La présente invention entend remédier aux inconvénients de l'art antérieur en permettant de faire apparaître une interactivité sur un élément d'une page numérique sans modifier la structure du circuit normal d'affichage. Le procédé de la présente invention possède de nombreux avantages par rapport aux procédés déjà connus : par exemple, il ne nécessite pas de plugin particulier installé sur la plate-forme cliente, et il n'exige pas qu'un bandeau soit développé au moyen d'un outil autre que ceux qui sont utilisés pour développer des pages Web en DHTML. De plus, la technologie de la présente invention est en mesure d' encapsuler des technologies tierces. Le procédé selon l'invention n'impose aucune modification propriétaire du bandeau originel et permet de séparer totalement l'aspect graphique du bandeau de sa logique applicative. Cette technologie permet également de livrer le bandeau indépendamment de sa logique interactive. Un avantage majeur du procédé de la présente invention est, qu'une fois qu'une structure d'interactivité est créée, il permet de la déployer sous de multiples formes telles qu'un bandeau publicitaire, une carte géographique ou un texte. De plus, ce procédé donne la possibilité de répercuter en temps réel les modifications relatives à l'interactivité sur le bandeau, et permet d'effectuer aisément le regroupement de plusieurs annonceurs sur un même bandeau. Il permet aussi de composer facilement des menus complexes à partir de menus élémentaires, ne fait intervenir l'agence que sur un serveur d'agence et idéalement uniquement sur un serveur de bandeau. Enfin, le procédé de la présente invention permet de rendre les bandeaux accessibles par les moteurs de recherche, permet aux sociétés de fournir leurs propres services que l'annonceur peut décider d'inclure dans sa structure arborescente et permet d'offrir aux designers la possibilité de fournir des modèles (aussi appelés templates ) que les annonceurs peuvent décider d'utiliser pour la présentation de leur interactivité. A cet effet, la présente invention concerne, selon son acception la plus générale un procédé d'enrichissement du contenu d'une page numérique dont le format permet la création de liens vers des objets informatiques, et dont la représentation s'affiche par le biais d'un support d'affichage, caractérisé en ce qu'il comprend : # une étape de définition d'au moins une structure arborescente dont les feuilles correspondent à des codes cibles ; # une étape de définition d'au moins un élément ; # une étape de création d'au moins un marqueur originel, incluant un lien audit élément ; # une étape d'enrichissement du marqueur originel consistant en la génération d'un nouveau marqueur substitué audit marqueur originel, ledit marqueur originel étant modifié à partir : du contenu du marqueur originel, d'une (de) référence (s) ladite (auxdites) structure (s) arborescente (s) et d'un moyen de déploiement de la représentation de ladite structure arborescente ; # une étape d'adjonction, dans la page numérique, d'un lien vers le marqueur enrichi ; # une étape d'affichage de la représentation dudit marqueur enrichi conduisant à une représentation enrichie dudit élément ; # une étape de déploiement de la représentation de ladite structure arborescente dans le support d'affichage, après action d'un utilisateur sur la représentation enrichie dudit élément. De préférence, ladite étape de définition d'une structure arborescente comprend une sous-étape de stockage d'une structure arborescente ou d'un mécanisme permettant de créer dynamiquement une structure arborescente en fonction de paramètres de contexte. Selon une première variante, le stockage a lieu sur un serveur dédié. Selon une autre variante, le stockage a lieu en local. Avantageusement, le stockage a lieu avec le marqueur originel. Avantageusement, le stockage est effectué sous forme de fichiers, ces fichiers étant des fichiers de format SGML ou d'un format dérivé du SGML, des fichiers de format XML ou d'un format dérivé du XML, des fichiers de format DHTML, des fichiers de format binaire, des fichiers de format pré-compilé ou des fichiers de format texte. Selon une variante, le stockage est effectué dans une base de données numérique, cette base de données numérique étant relationnelle ou objet. De préférence, ladite étape de définition d'une structure arborescente consiste en la création de cette structure arborescente. Avantageusement, ladite étape de définition d'une structure arborescente consiste en la modification d'une structure arborescente déjà existante. Selon un mode de mise en #uvre particulier, ladite étape de définition d'une structure arborescente consiste en la composition d'une structure arborescente à partir d'au moins deux structures arborescentes déjà existantes, ces structures arborescentes n'étant pas nécessairement distinctes les unes des autres. Selon une première variante, ladite modification consiste en la suppression d'un n#ud de ladite structure arborescente déjà existante. Selon une seconde variante, ladite modification consiste en la création d'un nouveau n#ud de ladite structure arborescente déjà existante. Selon une autre variante, ladite modification consiste en la modification d'un n#ud de ladite structure arborescente déjà existante. Selon une autre variante, ladite modification consiste en le déplacement d'un n#ud de ladite structure arborescente déjà existante. De préférence, ladite composition consiste en le rattachement d'un fragment ou de la totalité d'une des structures arborescentes déjà existantes à une autre structure arborescente déjà existante. Selon une variante, l'utilisateur est un être humain. Selon une autre variante, l'utilisateur est un automate. Selon un premier mode de mise en #uvre, le moyen de déploiement est de nature logicielle. Selon un second mode de mise en #uvre, le moyen de déploiement est de nature matérielle. Avantageusement, le support d'affichage est un programme installé en local. Selon une variante, le support d'affichage est un navigateur web. Selon une autre variante, le support d'affichage est un plug-in associé à un navigateur web. Selon un mode de mise en #uvre particulier, le support d'affichage est implémenté sur un système embarqué. Selon un autre mode de mise en #uvre particulier, le support d'affichage est implémenté sur un ordinateur personnel. Selon une variante, le support d'affichage est implémenté sur une borne interactive. Selon une autre variante, le support d'affichage est implémenté sur un appareil de télévision interactive. Selon une autre variante, le support d'affichage est implémenté sur un appareil nomade. De préférence, l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un événement souris ou en un événement clavier. Avantageusement, l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un signal sonore. Avantageusement, l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un événement tactile. Selon une variante, l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un automatisme déclenché par le contexte. Avantageusement, le contexte est la situation géographique physique de l'utilisateur. Selon un mode de mise en #uvre particulier, le contexte est un mot-clé. Selon un autre mode de mise en #uvre particulier, le contexte est la date. Selon une variante, le contexte est la situation géographique telle qu'elle est désignée par l'utilisateur. Selon une autre variante, le contexte est une contrainte prédéfinie à l'avance. De préférence, ladite page numérique est un support de carte. Avantageusement, ladite page numérique est un support de contenu multimédia ou textuel. Avantageusement, ladite page numérique est un support d'objet informatique. De préférence, ladite page numérique est une page statique ou dynamique écrite en DHTML, XML, HTML, CHTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Selon une variante, ladite page numérique est une page statique ou dynamique contenant du code écrit en DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Selon une autre variante, ladite page numérique est une page statique ou dynamique faisant appel à du code écrit en DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Selon un mode de mise en #uvre particulier, ladite page numérique est une page numérique statique ou dynamique, mettant en #uvre une animation Flash. De préférence, ledit marqueur originel est constitué d'un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Avantageusement, ledit marqueur originel contient un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Avantageusement, ledit marqueur originel fait appel à un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Selon un mode de mise en #uvre particulier, ledit marqueur originel est un programme compilé ou précompilé, du code ASCII ou du texte. De préférence, ledit marqueur originel est un fichier, ce fichier est un fichier multimédia, un fichier texte, un fichier de format SGML ou d'un format dérivé du SGML, un fichier de format XML ou d'un format dérivé du XML, un fichier de format DHTML ou un fichier de données. Avantageusement, ledit marqueur enrichi est constitué d'un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Avantageusement, ledit marqueur enrichi contient un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Selon une variante, ledit marqueur enrichi fait appel à un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Selon un mode de mise en #uvre particulier, ledit marqueur enrichi est un programme compilé ou pré-compilé, du code ASCII ou du texte. De préférence, ledit marqueur enrichi est un fichier, ce fichier est un fichier multimédia, un fichier texte, un fichier de format SGML ou d'un format dérivé du SGML, un fichier de format XML ou d'un format dérivé du XML, un fichier de format DHTML ou un fichier de données. Selon un mode de mise en #uvre particulier, ladite structure arborescente est réduite à une simple feuille. De préférence, lesdits codes cibles sont des références à des fichiers cibles constitués d'un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Avantageusement, lesdits codes cibles sont des références à des fichiers cibles contenant un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Avantageusement, lesdits codes cibles sont des références à des fichiers cibles faisant appel à un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. Selon une variante, lesdits codes cibles sont des références à des fichiers multimédias, ces fichiers multimédias étant des fichiers sons, animations ou vidéos. De préférence, lesdits fichiers multimédias sont diffusés sous forme de streaming. De préférence, ladite représentation dudit marqueur enrichi est un ensemble de menus et sous-menus imbriqués. Avantageusement, ladite représentation dudit marqueur enrichi est un ensemble de listes déroulantes distinctes. Selon une variante, ladite représentation dudit marqueur enrichi est un ensemble de zones sensibles d'un fichier multimédia. De préférence, les feuilles de ladite structure arborescente correspondent à des liens dynamiquement créés en fonction de conditions résolues au moment de la requête de l'utilisateur. Avantageusement, les feuilles de ladite structure arborescente correspondent à des liens statiques. De préférence, ladite structure arborescente est créée via une interface de création. Selon une variante, ladite interface de création est accessible en ligne. Selon une autre variante, ladite interface de création fait partie d'un logiciel installé sur le poste de l'utilisateur de ladite interface. Selon un mode de mise en #uvre particulier, ladite étape de définition d'une structure arborescente consiste à appeler une structure arborescente préalablement enregistrée sur un support d'enregistrement. Avantageusement, ledit support d'enregistrement est un support amovible. De préférence, le marqueur originel fait référence à un bandeau publicitaire. Selon une variante, le marqueur enrichi fait appel dynamiquement aux structures arborescentes relatives aux mots dynamiquement chargés sur la page numérique. Selon une autre variante, le marqueur enrichi fait appel dynamiquement aux structures arborescentes relatives à l'intersection d'un contexte géographique et d'un contexte thématique chargés dynamiquement sur la page numérique. Selon un mode de mise en #uvre particulier, l'étape d'affichage dynamique de la représentation dudit marqueur enrichi inclut des modifications dynamiques de la page numérique. La présente invention se rapporte également à une architecture informatique multi-serveurs caractérisée en ce qu'elle comprend notamment : # un poste client appelant une page numérique dont le contenu est enrichi selon le procédé susvisé ; # un serveur d'éléments stockant des éléments ; # un serveur contenant des règles d'appel aux dites références vers lesdits éléments ; # un serveur dédié contenant les structures arborescentes ; # un serveur web contenant ladite page numérique. De préférence, l'architecture comprend en outre un serveur contenant des références vers lesdits éléments et des règles d'appel vers lesdits éléments Avantageusement, l'architecture comprend en outre un deuxième serveur web contenant des fichiers cibles. Selon une variante, les éléments sont des pages de texte. Selon une autre variante, les éléments sont des figures géométriques ou des mots, en ce que le serveur web contenant ladite page numérique est un serveur spatial. On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées : # la figure 1 représente une structure arborescente ; # la figure 2 illustre des structures arborescentes conditionnelles ; # la figure 3 illustre les différentes définitions de base ; # la figure 4 représente la production d'un élément par un serveur d'élément ; # la figure 5 compare la représentation de l'élément dans plusieurs cas de déclinaison de l'invention ; # la figure 6 représente les différentes phases du procédé selon l'invention ; # les figures 7 et 8 représentent une modélisation du marché de l'e-publicité : la structure technique et les acteurs ; # la figure 9 représente les renvois, par le biais du navigateur, au cours de la phase d'affichage ; # la figure 10 représente un exemple d'interface de création de service ; # la figure 11 représente un exemple d'interface de création de structures arborescentes ; # la figure 12 représente la traçabilité des variables au cours des différentes phases ; # la figure 13 illustre un exemple d'interface de saisie permettant à une agence d'associer un arbre stylisé à un bandeau publicitaire de son client annonceur ; # la figure 14 illustre le principe de la phase de production de Rich-Banner ; # la figure 15 présente les phases de production de Rich-Banner ; # la figure 16 présente un procédé possible d'une phase de production de la Rich- Banner conforme à l'invention ; # la figure 17 illustre un exemple de Rich- Banner dont un menu est déployé et une minipage affichée ; # la figure 18 illustre le cas d'une technique traditionnelle de l'e- publicité ; # la figure 19 représente un procédé possible d'une phase de production de la Rich-Banner conforme à l'invention (cas du tag iframe) ; # la figure 20 illustre un exemple d'interface relative à la phase de développement de Rich-Word ; # la figure 21 illustre un procédé possible d'une phase de production de Rich-Word ; # les figures 22 et 23 illustrent le principe théorique du Rich-Word ; # la figure 24 illustre la notion d'association dans le cas du Rich-Word ; # la figure 25 illustre le principe des zones sensibles d'une image ; # La figure 26 illustre le principe de Rich-Image ; # la figure 27 représente un exemple d'interface d'une phase de développement dans le cas de Rich-Image ; # la figure 28 représente un procédé possible d'une phase de production dans le cas de Rich-Image ; # la figure 29 représente un exemple d'interface d'une phase de développement dans le cas de Rich-Geobject ; # la figure 30 représente un procédé possible d'une phase de production dans le cas de Rich-Geobject ; # les figures 31 et 32 illustrent le principe de l'élément permanent dans le cas du Rich-Miniportail ; # la figure 33 illustre la participation des arbres actifs au processus de recherche d'un moteur de recherche. Une structure arborescente (ou arbre) est un code structuré représentant, par imbrications successives, une arborescence susceptible de présenter une information structurée, propice à une navigation structurée telle que des menus et des sous-menus (Mijk). Les terminaisons (ou feuilles) de l'arbre représentent des codes cibles que l'on peut représenter, dans la technologie XML, sous la forme de n#uds texte (TCijk)(TC : target code). Un tel n#ud texte peut, par exemple, correspondre, à l'adresse HTTP absolue d'une page Web. Ces adresses permettront alors d'accéder aux pages Web correspondantes à l'occasion d'une phase dite d'utilisation (voir plus loin). Ces pages Web sont appelées minipages . Chacun des n#uds de la structure arborescente peut être accompagné d'attributs particuliers, propres à leur conférer des fonctionnalités spécifiques, comme la possibilité d'obtenir une minipage Web en cliquant au niveau d'un menu qui n'est pas une feuille. La figure 2 représente une structure de menu classique dont les menus et feuilles ont un nom, et dont les feuilles ont un nom et une page cible. Des structures arborescentes plus complexes peuvent être envisagées, comme nous le verrons par la suite, notamment : # des attributs de style (couleur ...), # des pages cibles sur des menus qui ne sont pas des feuilles, # des attributs conditionnels permettant d'incorporer, au sein même de l'arbre, par exemple en attribut condition de l'élément menu , les conditions d'affichage dudit menu en fonction, par exemple, des caractéristiques de la plate-forme cliente, déterminées à l'aide de l'en-tête de la requête, etc. Les conditions peuvent être placées à n'importe quelle place de l'arbre, par exemple sous la forme d'un attribut dont la valeur est un script.On peut également considérer des conditions contextuelles de déploiement à l'instant, par exemple, du clic de la souris sur une commande correspondant à une feuille de l'arbre. Un arbre est dit stylisé lorsqu'il lui a été adjoint un certain nombre d'attributs stylistiques (par le biais ou non d'une feuille de style externe). Un arbre non stylisé ne contient que des données structurées, tandis qu'un arbre stylisé est prêt à être présenté graphiquement, puisqu'il contient aussi bien des styles de présentation (couleur, police de caractère ...) que des styles d'interactivité (animation d'ouverture de menus...). Un arbre est dit actif lorsqu'il est inséré dans une chaîne de production pouvant conduire à son affichage sur la plate-forme cliente d'un internaute. Un arbre actif a nécessairement été stylisé au préalable. Un arbre (même s'il est stylisé) ne peut pas être affiché sur une plate-forme cliente s'il n'a pas été activé au préalable. On entend par serveur d'arbre un serveur stockant et restituant des structures arborescentes à la demande. Un élément est un fichier informatique pouvant représenter un objet multimédia (fichier image, fichier vidéo ...) ou mécanisme permettant de créer dynamiquement un tel objet informatique. Un élément est stocké sur un serveur d'élément. Le marqueur originel est un code incluant une référence à un élément. Le marqueur enrichi est le marqueur obtenu à partir de l'enrichissement d'un marqueur originel, ce qui conduit à une représentation enrichie de l'élément du marqueur originel, représentation sur laquelle un utilisateur (internaute ou application) effectue une action afin de déployer la représentation de la structure arborescente qui lui a été associée, à l'occasion d'une phase dite phase de développement . On parlera de support de consultation par généralisation de la page Web, objet de la consultation de l'internaute. Dans le cas particulier d'un code cible faisant référence à un fichier cible qui est une page Web, cette dernière est appelée minipage . Elles sont souvent affichées dans une petite fenêtre (pop-up) à l'occasion de l'action opérée par l'internaute sur la commande d'un menu déployé. Un serveur d'arbre sert un ensemble de menus qui vient graphiquement se greffer sur la représentation d'un élément (bandeau, figure géométrique ...), cet élément étant médiatisé (au sens d'un moyen (média) de transport) par un support (respectivement la page Web, la carte, ...) . Une fois la greffe réalisée, on peut considérer que l'élément est enrichi d'une structure de menu qui lui permet d'atteindre à travers les minipages vers lesquelles pointe chacune des commandes auxquelles on accède par le biais de ces menus. Il s'agit, en fait, d'une représentation enrichie de l'élément, et par abus de langage, d'un élément enrichi . Ces commandes se réfèrent par exemple aux URL indiquant, chacune, l'adresse d'une page Web (statique ou dynamique), et que l'on appelle les minipages . Cette structure de menu peut être considérée comme une structure de navigation dans le sens où cette structure permet de naviguer à travers ces minipages . Les définitions précédentes peuvent s'appuyer sur la production d'un élément par un serveur d'élément comme décrit sur la figure 4. Un serveur d'élément (SE) produit un élément (E) sur une plate-forme cliente lorsque, suite à une requête (R1) de la part de ladite plate-forme cliente sur un serveur de référence d'élément (SR) (phase 1), ledit serveur de référence d'élément lui répond par l'envoi d'un code(Cl) (phase 2) qui encapsule un code cl, interprétable par une machine virtuelle(MV) installée sur ladite plateforme cliente, code faisant référence à l'adresse url(E) dudit élément E sur un serveur d'élément (SE) et ayant pour finalité l'affichage graphique dudit élément sur ladite plate-forme cliente. L'interprétation du code Cl (Cl=document.write(cl) (par exemple en Javascript) conduit à désencapsuler cl qui est alors interprété par la machine virtuelle (MV). La machine virtuelle MV détecte une balise (phase 3) qu'elle interprète en cherchant la valeur d'un attribut lui indiquant l'adresse url(E) de l'élément E sur le web(phase 4) qui lui permet de le requêter (phase 5). Le serveur d'élément SE produit alors l'élément E en téléchargeant son code vers la plate-forme cliente (phase 6). Le navigateur traite alors ce code à des fins d'affichage sur la plate-forme cliente (phase 7). La présente invention peut, entre autres, avoir les déclinaisons suivantes : # Rich-Banner : bandeau publicitaire enrichi d'une structure de menus déployable. # Rich-Geobject : élément géométrique (composé de primitives géométriques) en surimpression d'une carte géographique, et duquel l'internaute, en passant la souris par-dessus, déploie une structure de menus correspondante. # Rich-Word : mot à partir duquel l'internaute, en passant la souris par-dessus, déploie une structure de menus adaptée. # Rich-Image : élément géométrique en surimpression d'une image (gif, jpeg, png ...), ou zone sensible, desquels l'internaute, en passant la souris par- dessus, déploie une structure arborescente de menus correspondante. L'arborescence en question peut aussi se concevoir sous la forme d'un chemin dont les zones sensibles d'une image sont les guides vers les prochaines images. # Rich-Miniportail : structure de menus adaptée aux besoins particuliers d'un individu et déployable à partir d'un élément sur une page Web. Idéalement, cet élément est permanent, c'est-à- dire qu'on le retrouve de page Web en page Web, au fur et à mesure de la navigation de l'internaute, à la même position par rapport à la fenêtre contenant la page Web, et dans le même état (menus déployés ou non). Le terme rich , qui apparaît communément, indique que chacun de ces éléments est enrichi d'une structure arborescente déployable par une action d'un utilisateur (internaute ou application) sur la représentation enrichie de l'élément. Le procédé de la présente invention présente de nombreuses propriétés très intéressantes pour l'homme du métier. Par exemple, une structure arborescente est réutilisable par un annonceur pour ses déploiements sous de multiples formes, notamment : bandeau publicitaire (RichBanner), carte géographique (Rich-Geobject), texte (RichWord) ... Autrement dit, il s'agit d'un write once, inform anywhere . Le déploiement graphique de la structure arborescente, par action d'un utilisateur sur la représentation enrichie d'un élément, permet à celui-ci de consulter des informations et d'utiliser des services, tout en restant sur le support de l'élément. Il reste ainsi maître de sa navigation. La répercussion des modifications faites par l'annonceur sur sa structure arborescente est effective en temps réel. Des structures arborescentes appartenant à des annonceurs différents peuvent être associées ensemble à un même élément, permettant ainsi à un utilisateur, lorsqu'il déploie graphiquement cette structure arborescente, de consulter les informations ou d'utiliser des services correspondant à des annonceurs différents. De plus, il est possible à un annonceur d'assembler des briques de structures arborescentes afin de composer une structure plus complexe. Les diverses déclinaisons de la présente invention doivent tenir compte des contraintes de la chaîne d'acteurs impliqués dans le marché visé. Dans le marché particulier de l'e-publicité, la non-intrusion consiste, dans l'idéal, à n'intervenir ni sur les serveurs de publicité de régie, ni sur les serveurs de publicité d'agence. Idéalement, on n'intervient alors que sur le serveur de contenu délivrant l'élément, objet de la création publicitaire. Idéalement encore, il n'y a aucune intrusion dans le processus de création de l'objet publicitaire. Il s'agit alors d'adjoindre un élément totalement complémentaire à l'objet publicitaire créé par l'agence. Ainsi, il est possible d'obtenir des reportings détaillés en temps réel, permettant aux agences et à leurs clients annonceurs de déterminer les paramètres de succès de telle ou telle création publicitaire, afin de disposer d'une base de connaissance exploitable pour les prochains plans médias, et de réajuster des paramètres en cours de campagne. Le procédé selon l'invention permet aussi bien d'encapsuler un grand nombre de technologies existantes (java applet, flash payer, gif ...) que de s'intégrer au sein de ces technologies. Les agences doivent investir le moins possible de ressources dans l'apprentissage de nouvelles méthodes propres à la nouvelle technologie. Idéalement, on doit pouvoir scinder un fichier obtenu par ces outils en une composante arborescente (structure et données) et une composante purement stylistique (style et interactivité). Enfin, les arbres créés et activés (c'est-à-dire prêt à être diffusés sur demande) sont accessibles par les moteurs de recherche, même s'ils ne font pas partie explicitement du contenu d'une page Web. Une défaillance de l'affichage de l'arbre ne doit pas être préjudiciable à celui de l'élément, que cela soit sur le plan du délai ou de l'affichage proprement dit. Offrir aux sociétés la possibilité de fournir leurs propres services que l'annonceur peut décider d'inclure dans sa structure arborescente. Offrir aux designers la possibilité de fournir des modèles (templates) que les annonceurs peuvent décider d'utiliser, de façon exclusive ou non, pour la présentation de leur structure arborescente. Le procédé de la présente invention comprend trois différentes phases : # une phase de pré-développement ; # une phase de développement ; # une phase de production. La phase de pré-développement est la phase correspondant, de façon totalement indépendante, à : # La création des arbres ou d'un mécanisme de création dynamique d'arbres : on inclue dans cette phase les créations des arbres (données et structure), des feuilles de style des arbres, et des moyens de déploiement et d'interactivité des arbres. # La création d'éléments ou d'un mécanisme de création dynamique d'éléments. # La création des marqueurs. # La création des minipages ou d'un mécanisme de création dynamique des minipages. # La création des services. La phase de développement est la phase durant laquelle on enrichit un marqueur en lui associant un arbre stylisé avec moyen de déploiement, phase accompagnée de la substitution du marqueur originel par le marqueur enrichi. Cette phase peut également consister en le stockage de l'association entre un élément et un arbre et son moyen de déploiement : c'est le cas, par exemple, du procédé qu'utilise Rich-Word. La phase de production est la phase initiée par la requête d'un internaute ou d'une application. La phase de production comprend elle-même trois phases : # La phase d'affichage. Il s'agit de la phase initiée par un internaute ou une application, et dont le terme correspond à l'affichage de la représentation enrichie de l'élément. # La phase de déploiement. Il s'agit de la phase initiée par une action d'un utilisateur sur la représentation enrichie de l'élément et dont le terme correspond au déploiement graphique de la structure arborescente. Il peut s'agir notamment d'un déploiement de menus et sous- menus codés dans un langage compréhensible par la plate-forme cliente, ce qui est par exemple le cas du JavaScript dans une page Web. # La phase d'utilisation. Il s'agit de la phase correspondant à des actions de l'utilisateur sur un ou des menu(s), sous- menu(s) ou commande(s) de la structure arborescente graphiquement déployée. Elle entraîne, une fois une feuille sélectionnée, l'exécution du code cible associé, ce qui peut conduire, par exemple, avec un code client JavaScript approprié, à l'affichage d'une minipage Web dans une fenêtre ouverte à cet effet. Sur la figure 6, on observe les éléments suivants : MD : Moyen de déploiement MP : Plan media Link (MP): Lien au Plan media M : Marqueur originel RM : Marqueur enrichi (Rich Marker) E : Element RE : Rich Element Link (E): Lien à l'élément E T : Tree (structure arborescente) Link(Menu): Lien à un code modifiable par le biais de 3 interfaces (arbre, style et MD) La phase de pré-développement est indiquée par les quatre flèches de la colonne phase de pré- développement . La phase de création des arbres peut consister à créer des mécanismes permettant d'obtenir dynamiquement les arbres, en phase de production, en fonction de paramètres de contexte. La création d'un arbre (ou d'un mécanisme de création d'arbre) peut se faire à partir d'un arbre existant que l'on modifie, ou par composition de deux arbres, l'arbre résultant étant obtenu par la greffe de la racine de l'un sur une feuille de l'autre. La phase de création des arbres peut, indépendamment, consister à utiliser trois interfaces séparées et dédiées à la création des données et de la structure de l'arbre, à la création des attributs stylistique de l'arbre et à la création de ses moyens de déploiement et d'interactivité. L'utilisation de ces interfaces conduit, par exemple, à la création d'un fichier JavaScript (extension js) pour les moyens de déploiement et d'interactivité, à la création d'une feuille de style (extension css) pour les attributs stylistiques de l'arbre ainsi que d'un fichier xml pour l'arbre proprement dit (structure et données). On peut également concevoir qu'à l'issue de la phase de pré-développement, les données, la structure et le style de l'arbre soient incorporées dans un même fichier JavaScript. La phase de développement est indiquée sur la figure 6 par les trois flèches en pointillés, conduisant à la création d'un marqueur enrichi (RM), stocké sur le serveur de marqueur en substitution du marqueur originel (M). La phase de production (cas de la RichBanner) peut être décrite comme ceci (en se référant à la figure 6) : Al : Consultation d'une page Web par un internaute A2 : Le serveur Web contenant la page délivre la page Web objet de la consultation : c'est la page de consultation . A3 : Le tag publicitaire, préalablement fourni par la régie et inséré par le Webmestre dans le code source de la page Web consultée, fait appel au serveur de publicité de la régie ou serveur de marqueur . En tenant compte de paramètres de contexte, le serveur de publicité de régie choisi un des marqueurs enrichis (RM) parmi ceux qu'il a en stock. Ce marqueur enrichi comprend un lien nommé Link (MP) vers un plan média et un lien nommé Link(Menu) vers un arbre. A4 : Le marqueur enrichi contient une référence à un plan média (MP). La méthode JavaScript write de l'objet document permet d'écrire le lien vers le plan média (MP) dans le DOM de la page de consultation. A5 : Le lien s'effectue donc vers le un serveur de publicité d'agence qui est un serveur de référence d'élément . Il s'agit d'un mécanisme permettant au serveur de publicité d'agence, en fonction des paramètres de contexte, de choisir une référence d'élément (Link(E)). A6 : La méthode JavaScript write de l'objet document permet d'écrire le lien vers l'élément (E) dans le DOM de la page de consultation. A7 : Le lien s'effectue donc vers le serveur de contenu, dit serveur d'élément , à l'aide de la référence link(E), afin d'extraire l'élément E. A8 : Affichage de l'élément E sur la plate-forme cliente de l'internaute. A9 : Le marqueur enrichi contient une référence (Link(Menu)) à un ensemble constitué d'une structure arborescente (T), d'une feuille de style et d'un moyen de déploiement (MD), incluant les règles de déploiement et d'interactivité de ce menu. Cet ensemble est stocké sur un serveur, dit serveur d'arbre . Peut également y être stocké un mécanisme permettant au serveur d'arbre, en fonction des paramètres de contexte, de constituer dynamiquement l'arbre en question. La méthode JavaScript write de l'objet document permet d'écrire le lien Link (Menu) dans le DOM de la page de consultation. A10 : Le lien s'effectue donc vers le serveur d'arbre, à l'aide de la référence Link (Menu) fait, par exemple, référence à un fichier JavaScript externe ( ), fichier constitué d'une série de commandes encapsulées dans des méthodes write de l'objet document afin d'écrire dans le DOM de la page de consultation. All : Affichage de l'arbre (données, structure et style) accompagné de son moyen de déploiement et d'interactivité (MD) et téléchargement de l'ensemble de ce code sur la plate-forme cliente. Il peut être affiché ou attendre une action d'un utilisateur pour se déployer de façon visible sur la plate-forme cliente. Dans le tableau suivant, les définitions sont présentées dans le cas des quatre déclinaisons de la présente invention : Rich-Banner Rich-Geobject Rich-Word Rich-Image Affichage Déclenchement Consultation Requête Consultation Consultation d'un site web spatiale d'un site Web d'un site Web par un & thématique par un par un internaute internaute internaute Plugin Aucun SVG ou FLASH Aucun Aucun Serveur du Serveur Web Serveur spatial Serveur Web Serveur support de de contenu consultation Elément Type Bandeau objet graphique Mot Image publicitaire de géométrie élémentaire : cercle, rectangle, polyline, polygone... Format Gif, Jpeg, SVG, FLASH, Text Gif, Jpeg, Flash, DHTML... DHTML Png... Support Page Web Carte Noeud texte du Page Web géographique DOM d'une page imbriquée dans Web une page Web Serveur de Serveur de Serveur spatial Serveur Serveur l'élément bandeau de contenu de contenu Plugin Aucun SVG ou FLASH Aucun Aucun Déploiement Déclenchement Mouse over Mouse over Mouse over Mouse over Plugin Aucun (DHTML) SVG Aucun (DHTML) Aucun (DHTML) Utilisation Action de Click sur Click Click Click sur l'internaute commande de sur commande Sur commande commande de menu de menu de menu menu Format Fenêtre DHTML Fenêtre DHTML Fenêtre DHTML Fenêtre DHTML Minipage Tableau 1 : définitions dans le cas de quatre déclinaisons de l'invention. Les figures 7 et 8 représentent une modélisation du marché de l'e-publicité : la structure technique et les acteurs. En se référant aux figures 7 et 8, on remarquera que l'agence graphique GD~m0 conçoit le visuel de la publicité GC de l'annonceur AD~i1j1 puis remet ce visuel à l'agence de centrale d'achat AG-il. L'agence de centrale d'achat AG~i1 consulte le plan média et détermine les sites Web PS~i2j2 qui ont été sélectionnés. Ces sites Web déterminent les régies PB~i2 qui ont pour charge de gérer les espaces publicitaires des sites Web PS~i2j2. L'agence de centrale d'achat AG~i1 remet alors aux régies PB~i2 ainsi sélectionées, un tag, dit "tag agence" et comprenant une référence à ce visuel. Cette remise est faite soit par le biais d'un envoi d'email au trafficker de la régie, soit par le biais de la saisie, par le trafficker de l'agence de centrale d'achat AG~il d'une interface du serveur de publicité AS~i2 de la régie PB~i2. Lorsqu'un internaute consulte une page du site Web PS~i2j2,dans laquelle le Webmestre dudit site a placé un tag, dit tag publicitaire , ce dernier appelle sa régie PB-iz . Le serveur de publicité AS~i2 de la régie PB~'2 régie effectue un processus au cours duquel il décide du tag agence qu'il va écrire dynamiquement dans le navigateur de l'internaute (ou vers lequel il va se diriger dans le cadre d'une redirection de serveur à serveur). Si le tag agence précédent est ainsi choisi, la requête est redirigée vers le serveur de contenu contenant le visuel publicitaire, serveur de contenu qui peut, ou non, être confondu avec le serveur de publicité AS-il de l'agence de centrale d'achat AG~i1. RichBanner peut encapsuler une technologie tierce richMedia, dans le sens où les menus se déploient autour de la création graphique richMedia. Les solutions technologiques tierces traditionnelles s'intègrent dans la production d'une publicité richMedia en étant serveur de bandeau (on dira plus généralement serveur de contenu), la spécificité de leur technologie nécessitant qu'ils hébergent entièrement la création graphique sur leur propre serveur. Dans ce cas, les serveurs de publicité d'agence ne doivent pas cumuler la fonction de serveur de contenu, mais laissent la main à un serveur de contenu séparé . Il y a donc une redirection de la requête du serveur d'agence vers un serveur de contenu externe. Avec RichBanner, il n'est pas question d'héberger la création graphique dans son entier, mais simplement un additif à celle-ci, sous la forme d'un arbre. Cela nécessite donc qu'un renvoi supplémentaire se fasse vers le serveur d'arbre. RichBanner est complémentaire des bandeaux technologiques propriétaires richMedia, à partir du moment où on a accès au tag agence afin de l'enrichir, ce qui est nécessairement le cas, car celui-ci doit être fourni au serveur de régie pour que le bandeau soit mis en traffick (envoyé par email ou par le champ d'un formulaire en ligne). Les renvois, par le biais du navigateur, au cours de la phase d'affichage sont illustrés figure 9. Des sites Web peuvent s'inscrire en tant que fournisseur de services (Service Provider [SP] en anglais). Une fois qu'ils ont fourni une URL de base et qu'un système sécurisé a permis de se faire techniquement confirmer que cette URL leur appartenait bien, un mot de passe est fourni au Webmestre de ce site. Ce mot de passe lui permet d'accéder à une interface grâce à laquelle il référence le site ainsi que ses services dans la base de données de fournisseurs de services. Le but d'un tel service est de permettre à un annonceur de les intégrer dans ses propres structures arborescentes. Si un service nécessite que l'annonceur saisisse des paramètres au moment de la création de sa structure arborescente, le fournisseur doit l'indiquer dans la rubrique Paramètres de l' URL , au moment où il crée le service. Si le service est géolocalisé, c'est-à-dire si le service est paramétré par un couple latitude/longitude (obtenu par la position du curseur sur une carte géographique ou bien par un GPS), le fournisseur le précise en cochant la case Service géolocalisé . Les champs Latitude et Longitude indiquent alors le nom des paramètres tels qu'ils doivent apparaître dans l'URL du service géolocalisé. Une URL dynamique peut être représentée sous la forme suivante : NomFichier.ext ? al=vl, ..., an=vn ext est l'extension de fichier et peut valoir notamment : asp, jsp, php, cfm ou xml. Les ai sont les noms de paramètres et v1 les valeurs de chacun de ces paramètres. Considérons une minipage dont deux paramètres ai1 et ai2 représentent respectivement les latitudes et longitudes. Le fournisseur de service doit alors renseigner les deux champs Latitude et Longitude dans l'interface de création des services, en leur donnant respectivement les valeurs ai1 et ai2 . Dans la suite, nous considérerons que le fournisseur de service a entré dans les champs Latitude et Longitude respectivement les valeurs lat et long . Cette convention nous permettra de tracer la variable tout au long du processus de production. L'interface de création de services est illustrée figure 10. L'interface présentée figure 11 permet à un annonceur de créer une structure arborescente en associant à chaque feuille de l'arbre un code cible ou bien directement l'URL d'une page Web. L'annonceur a le choix de saisir directement l'URL dans un champ texte prévu à cet effet (pour, par exemple, permettre à l'internaute d'afficher une minipage provenant de son propre site : on prévoit à cet effet la possibilité d'un glisser-déposer de la barre d'adresse du navigateur directement dans le champ de saisi de l'URL), ou bien de choisir, à l'aide d'une liste déroulante, un service parmi ceux proposés par les fournisseurs de service. Dans ce dernier cas, plusieurs possibilités : 1- L'annonceur n'a rien d'autre à saisir que le nom du service disponible dans la liste déroulante C'est le cas lorsque : 1. l'URL pointe vers une page statique 2. l'URL pointe vers une page dynamique dont les paramètres ne sont pas modifiables par l'annonceur 2. L'annonceur doit apporter des précisions à son choix C'est le cas lorsque : 2.Le service est semi-dynamique l'URL pointe vers une page dynamique dont les valeurs de certains paramètres de l'URL doivent être renseignés par l'annonceur. La saisie de ce service dans la liste déroulante, entraîne alors l'ouverture d'une fenêtre présentant un formulaire, dans lequel l'annonceur renseigne les valeurs des paramètres. La validation de ce formulaire entraîne la concaténation d'une chaîne de caractères conduisant à créer l'URL qui sera stockée dans la base de données des structures arborescentes. 3.Le service est totalement dynamique l'URL est dynamique et la valeur de certains paramètres ne seront renseignés qu'au moment du déploiement graphique de la structure arborescente : c'est le cas, par exemple, des paramètres correspondant à des coordonnées géographiques dont la valeur est déterminée par la position du curseur au moment du déploiement de la structure arborescente. La kième structure arborescente T~il jj1 k de l'annonceur AD~il j ,est sauvegardée dans une base de données dans un serveur d'arbre. Cela permettra ainsi de la déployer sur de multiples éléments : bannière publicitaire, mot d'un article ou élément géométrique sur une carte géographique. Cela permettra également d'associer, au sein d'un même élément, des structures arborescentes appartenant à des annonceurs différents, ceci même s'ils sont gérés par des agences différentes. La figure 12 (traçabilité des variables) illustre la production d'un service totalement dynamique dans le cadre du déploiement d'une structure arborescente sur un support cartographique. Pour effectuer la traçabilité des variables tout au long des différentes phases, on notera la réutilisation des deux variables lat et long comme définies dans le chapitre enregistrement des services . Si un service géolocalisé a été incorporé, les noms des paramètres géographiques renseignés par le fournisseur de service, à l'occasion de la création dudit service, apparaissent dans le fichier xml en tant que valeur de l'attribut en tant que valeur de l'attribut "name" des tags "param" imbriqués dans le tag "url". Dans une phase de développement, l'agence extrait de l'arbre multi-langues, un arbre mono-langue, ceci avant de l'associer à un élément. Ici, c'est la structure de langue anglaise qui a été extraite. Sont également déterminées les couleurs des fonds et titre des menus. Dans une phase de déploiement de la phase de production, l'internaute effectue un clic droit sur une carte, ou bien les coordonnées géographiques du lieu sont fournies par un GPS. Le javascript côté client, associé à la carte restituée par le serveur spatial, définit la valeur des deux variables latit et longit en correspondance avec la position du curseur sur la carte. Les menus sont affichés avec leur titre et leur couleur. Dans une phase d'utilisation de la phase de production, si l'internaute choisit la commande correspondant au service géolocalisé, le code javascript côté client concatène dynamiquement la chaîne de caractères formant l'url, en ajoutant à l'url de base définie dans le noeud texte du tag url, les deux paramètres "lat" et "long" auxquels il donne respectivement les valeurs des variables javascript globales "latit" et "longit". L'url ainsi formé, la page Web correspondante est affichée comme minipage dans une pop-up. Une interface de saisie, représentée sur la figure 13, permet à l'agence AG-il de saisir ou modifier la kième structure arborescente T~i1 j1 k de son client annonceur AD~il jl. Cette interface a pour objet de styliser l'arbre originel. L'arbre originel se limite à présenter des données de façon structurée. La phase de développement conduit à l'instanciation d'un arbre que l'on stylise . On entend par stylisation de l'arbre l'adjonction d'attributs stylistiques qui peuvent aussi bien être des attributs de couleur que d'interactivité. Techniquement, cela est réalisé idéalement par la transformation de l'arbre originel à l'aide d'une ou plusieurs feuille(s) de style, créée(s) par une agence graphique, et stockée (s) surle serveur d'arbre, éventuellement dans le cadre de la technologie XML (feuilles de styles XSL, XSLT), et/ou du standard DHTML (feuilles de style de type CSS). Ces feuilles de style ont pu être créées, par exemple, à l'aide d'outils graphiques standard tels que Flash ou Director. On entend par interactivité uniquement le style de cette interactivité (par exemple sous la forme d'une animation), à l'exception du résultat de l'action proprement dite, qui lui, est défini dans les feuilles de la structure arborescente. Le choix de l'arbre originel est décrit dans les étapes Al à A6. Al : L'agence entre un mot de passe A2 : Ce mot de passe lui donne accès à un ensemble d'annonceurs dont l'agence à la gestion (la liste déroulante Annonceur se remplit des noms de ces annonceurs). A3 : Le choix d'un des annonceurs donne accès à l'ensemble des structures arborescentes de cet annonceur (la liste déroulante Arbre se remplit des noms de ces arbres). A4 : L'agence choisit un annonceur dans la liste des annonceurs, ce qui a pour effet de requêter la base de données des arbres à la recherche des structures arborescentes appartenant à l'annonceur sélectionné. A5 : Lesdites structures arborescentes apparaissent parmi les possibilités de choix de la liste déroulante nommée Arbre . A6 : L'agence choisit un arbre dans la liste déroulante Arbre , ce qui a pour effet de remplir la liste nommée langage de l'ensemble des langues possibles. Cela est réalisé sans faire d'accès au serveur d' arbre. En effet, l'arbre sélectionné a été chargé dans le DOM de la page cliente. Une fois chargée, l'arbre a été parsé à la recherche des langues qu'il gère, ce qui a permis d'extraire les intitulés de ces langues. Ce n'est qu'une fois que le choix d'un arbre a été fait, et que ce dernier est donc chargé dans le DOM de la page cliente, que les boutons Color et Interactivité sont accessibles. Le choix d'une interactivité pour l'arbre stylisé est décrit dans les étapes Bl à B2. Bl : Un click sur le bouton interactivité conduit à ouvrir une fenêtre dont la page principale est fondée sur une requête sur les bases de données [GD] (Graphical Designer) et [GC] (Graphical Création). B2 : Cette page contient un formulaire permettant de définir le type d'interactivité que l'on désire associer au déploiement et à l'utilisation de l'arbre. La requête permet de proposer une liste déroulante, destinée à proposer des choix préétablis d'interactivité, en puisant ses valeurs dans une base de données comprenant des créations graphiques [GC]. Ces créations graphiques sont, idéalement, des feuilles de style qui ont été créées par des designers à l'aide, par exemple, d'outils standards de création graphique (Flash, Director ... ) , ou de façon plus directe (codage). Une fois effectué le choix d'une animation interactive, une portion Preview de la fenêtre permet de tester l'animation interactive dans le cadre de la structure arborescente sélectionnée. Le choix se fait par un clic sur le bouton OK , ce qui conduit à une modification dynamique du fragment XML correspondant, dans le DOM de la page cliente, à la structure arborescente en cours de stylisation. Le choix des couleurs (et plus généralement du style) de l'arbre stylisé (Cl) se fait par un clic sur le bouton color conduit à ouvrir une fenêtre contenant un formulaire permettant d'établir les couleurs des textes et fonds des éléments suivants de la structure arborescente : onglets, menus principaux et sous-menus. Par convention, un onglet et un menu de niveau le plus élevé (niveau 0 ou racine), un menu principal est un menu de niveau 1 et les sous-menus sont les menus de niveau strictement supérieurs à 1. On envisage dans la présente invention de mettre en #uvre un procédé d'aide au choix des couleurs de l'arbre ainsi qu'au choix d'autres attributs stylistiques. Une aide au choix des couleurs des éléments de menus définis précédemment (et du style en général) sera effectuée en considérant que ces couleurs doivent reprendre une partie des couleurs figurant dans le bandeau publicitaire. Comment, cependant, déterminer précisément leur valeur hexadécimale, étant donné qu'il n'est pas donné à la page Web un accès au fichier image constituant ledit bandeau ? Le bandeau publicitaire pointe, à l'aide de l'attribut href de la balise img , vers une page Web dont il reprend logiquement le style graphique et en particulier les couleurs. Ce style est défini, soit dans ladite page Web, cible du bandeau publicitaire, soit dans une feuille de style (CSS par exemple) à laquelle ladite page Web fait explicitement référence dans son code source. La solution consiste donc à importer le document HTML (sous forme XHTML par exemple) dont l'URL est définie en tant que valeur de l'attribut href de la balise img , de parser ledit document à la recherche d'occurrences de balises dont le nom est style , d'extraire enfin les valeurs des sous-attributs de ces balises correspondant à la définition des styles qui nous intéresse (par exemple : couleurs du fonds et du texte). S'il est fait explicitement référence, dans le code source de la page que l'on importe, à des feuilles de styles externes (par exemple feuilles de style CSS), on importe ladite feuille de style, dont l'URL est explicitement définie en valeur de l'attribut src de la balise style , et on procède d'une manière équivalente à celle qui précède, à ceci près que le parsing sera réalisé en tenant compte, en ce qui concerne une feuille de style CSS, de la différence entre la structure d'un document CSS et la structure d'un fichier XML. Dans le cas particulier de la couleur, une fois récupérées les valeurs hexadécimales, leur couleur résultante est affichée dans des listes déroulantes, permettant ainsi de choisir, parmi un ensemble restreint et cohérent de couleurs, tout en testant le rendu obtenu dans le cadre de la structure arborescente. Afin qu'il n'y ait aucune équivoque quant à l'URL vers laquelle pointe le bandeau publicitaire, un champ texte sera prévu à cet effet dans l'interface de développement, à moins qu'un processus soit en mesure de l'extraire à partir du champ texte dans lequel est écrit le marqueur originel. Ce procédé peut s'étendre au cas de l'extraction d'un minisite à partir du site cible du bandeau publicitaire. Cette extraction peut être semiautomatisée et consister en un accompagnement ayant pour objet la réalisation conjointe des minipages et de la structure arborescente. Il est également possible de réaliser une extension du procédé au cas d'une étroite intégration entre la structure arborescente et le fichier définissant le bandeau. C'est le cas, par exemple, dans lequel l'arbre stylisé fait partie intégrante du fichier définissant le bandeau publicitaire. Autrement dit, le déploiement des menus se fera au sein même du bandeau publicitaire qui peut être dans une technologie propriétaire. La présente invention s'applique également à ce cas, dès lors que l'on peut séparer la structure arborescente du reste du fichier définissant ledit bandeau. L'enregistrement de la structure arborescente stylisée en base de données est mise en #uvre dans l'étape El : El : Le fait de cliquer sur le bouton OK entraîne l'enregistrement de la structure arborescente stylisée dans la base de données des structures arborescentes. En terme, par exemple, de technologie XML, cela peut consister à mémoriser le fichier XML représentant la structure arborescente originelle, conjointement aux feuilles de style XSLT associées permettant de restituer, à la demande, l'arbre monolingue, en couleur et comprenant l'interactivité. Mais on peut très bien aussi opérer cette transformation au cours de la phase développement, si bien que l'on mémorisera alors, par exemple, un fichier javascript (js) comprenant l'ensemble de l'information permettant de déployer graphiquement l'arbre stylisé. L'étape d'enrichissement du marqueur originel correspond à E2 : E2 : Le marqueur originel, en général généré automatiquement par le serveur de publicité de l'agence, est collé dans le champ de l'interface prévu à cet effet. Il s'agit, dans le schéma ci-dessus d'un simple bandeau associé à un lien de type click-through. Le choix d'une option de l'interface Type de Tag va permettre au système de guider l'agence dans la création du marqueur enrichi à partir du marqueur originel : on parle alors d'un système semi-automatisé ou système d'aide à l'enrichissement du marqueur. Le marqueur enrichi consiste en l'adjonction d'un script (ou d'une référence à un script externe) au marqueur originel, ainsi qu'en l'adjonction d'un fragment représentant une structure arborescente (ou une référence à un tel fragment), ou représentant un mécanisme permettant de restituer dynamiquement et contextuellement une structure arborescente (ou une référence à un tel mécanisme). Le nouveau marqueur ainsi créé (le marqueur enrichi) intègre désormais du code (JavaScript par exemple) qui permettra, d'une part, d'insérer l'arbre stylisé extrait à partir de la base de données des structures arborescentes (l'enregistrement de l'arbre stylisé ayant été fait au cours de l'étape précédente (El), et d'autre part, d'assurer l'interactivité nécessaire au déploiement graphique et à l'utilisation de cette structure arborescente en adéquation avec le bandeau publicitaire. Une fois le marqueur enrichi récupéré, il est placé sur le serveur de publicité des régies en lieu et place des marqueurs originels. Afin de donner une description plus complète de l'invention, il est nécessaire d'aborder la problématique de la détermination du langage utilisé dans les menus déployés par le bandeau. Considérons le cas d'un internaute consultant un site Web depuis un ordinateur d'un café Web à l'étranger et partons du principe que ledit internaute ne comprend pas la langue dudit pays. Il y a de fortes chances pour que le navigateur de cet ordinateur ait été configuré de telle manière que sa langue par défaut soit celle du pays dans lequel il se trouve. Si donc la langue de la structure arborescente est déterminée dynamiquement dans le serveur d'arbre, au moment de la requête issue du navigateur, grâce à l'en-tête de cette dernière, cela signifie que la langue de la structure arborescente est déterminée en fonction des paramètres du navigateur, qui ont toutes les chances de correspondre au pays dans lequel se trouve l'ordinateur. Dans notre exemple, l'internaute verra se déployer une structure arborescente dans la langue dudit pays dont il ne parle pas la langue. Si le problème ne se pose pas avec des bandeaux publicitaires dont le message est clair, ceci indépendamment de la langue, la question devient incontournable en ce qui concerne la possibilité, pour ce bandeau, de déployer des informations plus fournies, ce qui pose le problème de la détermination de la langue. Une autre façon de déterminer la langue est de le faire au cours de la phase de développement et non au moment de la phase de production (phase d'affichage). Logiquement, la langue du menu du bandeau doit correspondre à celle de la page que consulte l'internaute et dans laquelle est inséré ledit bandeau. En effet, si l'internaute consulte cette page, c'est qu'il en comprend la langue. Nous supposerons, dans ce qui suit, que le choix de la langue correspondant au bandeau est fait lors de l'association de l'arbre audit bandeau, c'est-à-dire au cours de la phase de développement. Pour qu'il y ait alors adéquation linguistique entre la langue de l'internaute et les menus du bandeau enrichi, il faut que les contraintes suivantes soient respectées : # Si le bandeau originel a un attribut linguistique particulier (du texte ou un lien vers une page Web de langue donnée), on reposera sur le fait que le bandeau enrichi sera naturellement traffické sur des sites en adéquation linguistique avec le bandeau non enrichi. Autrement dit, le fait d'enrichir le bandeau n'influencera pas le plan média de la centrale d'achat. # Si le bandeau originel n'a pas d'attribut linguistique particulier (pas de texte ni lien vers une page Web invitant à un choix préalable de la langue), la centrale d'achat doit s'assurer que le marqueur, enrichi d'un appel à un arbre de langue donnée, est bien traffické sur des pages Web en adéquation linguistique avec ledit menu. En effet, tout bandeau enrichi est linguistiquement spécifique. Cela va nécessiter que la centrale d'achat réajuste son plan média. En se plaçant ainsi dans la chaîne des acteurs participant à la phase de production, le serveur d'arbre s'assure la capacité de compter le nombre d'affichages de la RichBanner. Afin que le serveur d'arbre puisse également participer au comptage à l'occasion de la phase d'utilisation, plusieurs possibilités peuvent être envisagées : 1- Des trackers post-click peuvent être placés dans les minipages de telle manière qu'un serveur soit informé à chaque fois qu'une telle minipage est affichée. 2- Lorsque le clic sur un menu n'est pas suivi de l'affichage d'une minipage, comme cela peut par exemple être le cas de l'affichage dynamique d'un formulaire en JavaScript, une requête d'insertion, présente au sein même du code cible, enregistrera l'activation de cette commande du menu. Chaque action sur les différents menus pouvant être enregistrée sur un serveur, le reporting est en mesure de s'appuyer sur le découpage de l'information représenté par la structure arborescente. Il est dès lors possible d'avoir des informations très précises concernant l'utilisation de l'interactivité de la Rich-Banner : aussi précise que le découpage réalisé par l'annonceur pour donner accès à son ensemble de fonctionnalités. L'idée repose sur le fait que l'on a la même information que celle délivrée par les trackers post-click des pages Web du site annonceur, à ceci près que ces informations sont obtenues à partir des choix de commandes de menus faits par l'utilisateur. Le principe de production de Rich-Banner est exposé figure 14. Par ailleurs, la figure 15 présente les phases de production de Rich-Banner. Le serveur web fournit la page web du support de la publicité, le serveur de publicité régie fournit le fichier contenant un lien vers le plan média, le serveur de publicité agence fournit un lien vers le bandeau publicitaire, le serveur de contenu fournit l'élément (par exemple : bandeau),le serveur d'arbre fournit la structure arborescente et le Serveur de mini-pages fournit les mini-pages que l'on appelle à partir du menu déployé de la RB. La figure 16 présente un procédé possible d'une phase de production de la RichBanner conforme à l'invention. C'est le cas du Tag Agence de type document.write (' '). Les étapes Al à A11, qui apparaissent sur la figure 16, reprennent les étapes Al à A11 dont il a été fait une explication précédemment. Voici comment peut se présenter le DOM (Document Object Model) de la page de consultation pour que fonctionne la RichBanner : /* Calque englobant à la fois le bandeau publicitaire, le logo de la technologie RichBanner ainsi que le (ou les) calque(s) du menu associé au bandeau publicitaire et les minipages*/ onMouseOver="javascript:document.getElementByld('div onglet ').style.visibility='visible';" onmouseout="javascript:document.getElementById('div~onglet' ).style.visibility='hidden';"> /* Bandeau publicitaire "ext" est une extension de fichier correspondant à une page Web statique (htm, html) ou dynamique (asp, php, cfm, jsp, xml). */ /* Calque comprenant le logo placé sur le bandeau publicitaire et indiquant que ce dernier est une RichBanner */ /* Calque comprenant le code permettant de déployer la structure arborescente */ /*Le menu est initialement caché*/ /*Référence à la fonction JavaScript incluant la structure de menus, son style et le code permettant son déploiement et l'interactivité*/ /*Les minipages sont initialement cachées*/ La figure 17 illustre le code qui précède. Le fichier menu.js , auquel il est fait référence à l'aide d'un chemin absolu dans l'attribut SRC de la balise SCRIPT, contient des instructions de type document.write , permettant d'écrire, dans le DOM de la page de consultation, les balises HTML (ainsi que leurs attributs et n#ud texte) permettant de visualiser la structure de menus. Il peut notamment y écrire des balises DIV afin de positionner des éléments de menu à n'importe quelle position, relativement à la bannière publicitaire à laquelle cette structure de menus est associée. Il y écrit également les références aux fonctions définies dans le fichier distant menu.js . Puisqu'il est fait appel aux instructions document.write au cours de la phase de chargement de la page Web, celles-ci conduisent à écrire dynamiquement dans la page Web sans que cette dernière ne se recharge. La figure 18 illustre le cas de la technique traditionnelle de l'e-publicité avec b : un bandeau B : Page web contenant le bandeau S : Page web support A : Page web annonceur IF : iframe H : hauteur de b et de IF W : largeur de b et de IF C'est le cas du Tag Agence de type document.write (' ') (ou ILAYER). Le bandeau traditionnel apparaît à travers une IFRAME. Ce cas diffère du cas où le marqueur était de la forme , dans la mesure où, dans le cas présent, il n'est pas fait explicitement mention du bandeau. Dans le cas du tag agence de type IFRAME, l'agence a la complète maîtrise de l'enrichissement du marqueur sans qu'il lui soit nécessaire de modifier le tag Agence qui se trouve sur le serveur de régie. Dans le cas du tag agence de type IMG, la marqueur était le tag Agence, tandis que dans le cas présent, le marqueur est la valeur de l'attribut SRC de l'IFRAME écrite dynamiquement dans le DOM de la page de consultation. La phase de développement : Dans le cadre de la présente invention, le marqueur originel est la page B. * Ce qui suit présente un exemple de procédé destiné à enrichir la page B. Au cours de la phase de développement, la page B est transformée en une page Bbis, qui est le marqueur enrichi. La phase de développement conduit à enrichir le marqueur originel B (page B. ext) d'un code client (par exemple écrit en JavaScript) obtenu à partir d'un arbre choisi parmi ceux que propose l'interface de développement, ainsi que d'attributs stylistiques et d'interactivité renseignés également par le biais de l'interface de développement. Le code client est nommé code arbre stylisé . c'est le moyen de déploiement. Un processus côté serveur (par exemple en Java) fabrique, à partir de l'arbre, un code interprétable par la plate-forme de l'internaute (par exemple JavaScript). Ce code doit permettre à l'internaute, une fois le processus d'affichage terminé, de déployer graphiquement l'arbre stylisé sur sa plate-forme (phase de déploiement) et de cliquer sur les menus ainsi déployés (phase d'utilisation), afin, par exemple, d'accéder à des pages Web (minipages) affichées dans des pop-up. Ce code est fabriqué au cours de la phase de développement lorsque sont associés un arbre (ou mécanisme de création d'arbre) et des attributs stylistiques et d'interactivité à une page Web. Une fois ce code fabriqué, il est incorporé dans la page B qui s'est ainsi enrichie pour devenir la page Bbis, page qui s'est également vue attribuée un certain nombre de fonctionnalités lui permettant, en phase de production, de réaliser des processus spécifiques. C'est ainsi, par exemple, que la balise BODY se voit attribuée une réaction spécifique à l'événement onLoad, ceci par le biais d'une fonction create~rb() , dont nous expliquerons le mécanisme dans le chapitre relatif à la phase de production. Conjointement, pour avoir accès à cette fonction, la page Bbis, doit inclure une référence au fichier rb.js la contenant. Toujours au cours de cette phase de développement, la page Bbis ainsi obtenue, a été placée à l'URL de la page B, de façon à être appelée par la page S en lieu et place de la page B initiale. Nous notons sur la figure 19 : S : Page web de consultation rb : Rich-Banner b : bandeau Code Menu : Javascript (permet de déployer l'arbre sur la plate-forme cliente) MP : Mini-Page B : page de l'agence contenant b avant sa transformation en Bbis Bbis : : Page web obtenu à partir de B dans la phase de développement T : Structure arborescente A: Page web de l'annonceur Al à A9 : phase d'affichage Ul & U2 : : phase d'utilisation IF1: tag iframe de la régie et placé sur la page web de consultation H : hauteur de b et de IF1 W : largeur de b et de IF1 urlBbis . url de la page B Plus précisement, la page support S est la page que consulte l'internaute. Le tag publicitaire correspond au tag que la régie demande au Webmestre de placer dans le code source de la page S. Le tag agence est de la forme document.write(' ') et est écrit dynamiquement dans le DOM de la page de consultation S . C'est l' iframe que nous noterons IF1 La valeur de l'attribut src (pour source) de l'iframe IF1 : c'est l'URL de la page B. L'internaute consulte la page support S (Al et A2). Le tag publicitaire requête l'adserver de la régie en lui fournissant, par exemple, l'URL de la page appelante (A3), ce qui permet au processus serveur de la régie de déterminer le tag Agence à sélectionner et restituer (A4). Nous considérons ici que le tag Document.write(' ') est choisi : l'iframe IF1 est alors chargé dans la page de consultation S. Ceci entraîne le chargement de la page Bbis (A5) en non plus de la page B originelle, puisque la page B a été remplacée par la page Bbis au cours de la phase de développement. A la fin du chargement de la page Bbis, l'événement onLoad de sa balise BODY est notifié. La valeur de l'attribut onLoad est la fonction JavaScript create- rb() qui est accessible puisque définie dans le fichier rb.js référencé dans la balise SCRIPT de la page Bbis. Cette fonction utilise l'instruction parent.parent.document afin de lui permettre, à partir de la page Bbis, de sortir de la balise DIV, puis d'accéder au DOM (document object model) de la page support S. Ainsi, l'expression parent.parent.document. getElementByTagName('iframe') permet-elle, par exemple, d'atteindre une balise iframe du DOM de la page S. (On peut noter que ceci n'est pas nécessaire si on décide d'intervenir directement sur le tag agence, considéré alors comme le marqueur originel, auquel cas on perd cependant l'avantage de n'intervenir que sur le serveur d'élément dans la phase de développement, ce qui est intéressant dans la mesure où cela rend le procédé encore moins intrusif). Il faut cependant déterminer le bon tag IFRAME, au cas où il y en aurait plusieurs sur la page de consultation. Lorsque l'iframe IF1 charge sa source, elle requête d'abord l'adserver agence (c'est la requête explicitement écrite en valeur de l'attribut SRC de l' iframe IF1). Cette requête restitue l' URL URL(Bbis)sur le serveur d'élément. Lorsque le code code arbre stylisé accède au DOM de la page S, il accède aux dernières valeurs chargées (ce qui n'est pas nécessairement identique au code source de la page S). En particulier, code arbre stylisé , en se référant à la valeur de l'attribut SRC de l'iframe IF1, accède à URL(Bbls) et non à la requête initiale sur l'adserver agence. On peut donc repérer, parmi plusieurs iframe, l'iframe dont l'attribut SRC a pour valeur URL(Bbls). ce que l'on fait en parcourant la liste obtenue à partir de l'instruction parent.document.getElementByTagName('iframe') et en stoppant la recherche lorsqu'un élément de cette liste a URL(Bbis) pour valeur de l'attribut SRC. (Il s'agit, par exemple, d'une boucle en JavaScript permettant d'extraire, un à un, les éléments elt de la liste et d'effectuer le test suivant : elt. src= URL(Bbis)). C'est au niveau de l'interface de développement que doit être précisée l' URL URL(Bbis), ce que l'on doit connaître si l'on veut ensuite l'enregistrer à la bonne place. La page S dont le DOM, juste avant le chargement de la page Bbis, était le suivant : S devient la page S' dont le DOM, à la suite de l'exécution de la fonction create~rb() et de son action conséquente sur le DOM de la page S, est maintenant le suivant : S' code arbre stylisé Il s'agit d'abord de l'imbrication de l'IFRAME (IF1) dans une balise DIV . Puis une seconde balise DIV est imbriquée dans la première, à la suite de la balise de fermeture de la balise IFRAME. Cette seconde balise DIV est destinée à accueillir le graphisme de l'arbre stylisé (par exemple sous forme de menus déroulants) associés au bandeau b. Ainsi l'attribution de valeurs aux attributs left et top de l'attribut STYLE de cette balise suffit à positionner le contenu de la seconde balise DIV relativement au coin supérieur gauche de la première balise DIV. H est ici la hauteur de l'IFRAME. Autrement dit, il est ainsi possible de positionner les menus déroulants précisément par rapport au bandeau b. On a placé code arbre stylisé (qui a été fabriqué au cours de la phase de développement) entre deux DIV. Ce code représente l'arbre stylisé, c'est-àdire l'arbre aussi bien du point de vue des données, du graphisme que de l'interactivité. Si, dans le cas du tag IMG, il était nécessaire d'encadrer le code de l'arbre stylisé entre deux DIV pour le positionner, ce n'est plus le cas ici, si l'on part du principe que le bandeau se trouve toujours en haut et à gauche de la page Web Bbis. Une fois affichée, la Rich-Banner peut être utilisée par l'internaute : il intéragit avec elle en déployant les menus et en cliquant sur les commandes qui apparaissent. Il a alors accès à des mini-pages et peut ainsi consulter le minisite Web de l'annonceur tout en restant sur la page support S. On aurait également pu concevoir que le fichier javascript distant http :// .../rb.js soit obtenu à partir de l'interface de développement et contienne l'arbre stylisé (au lieu que cela soit la page Bbis qui le contienne). Si le nom de fichier rb.js ne change pas d'un arbre à un autre, le chemin y accédant est spécifique à l'arbre en question et est stocké sur le serveur d'arbre. L'interface de développement se charge de réaliser l'automatisme consistant à créer un nouveau chemin à chaque création d'arbre, et à modifier la page Bbis afin qu'elle fasse référence au bon fichier rb.js . Considérons le cas du Tag Agence de type document.write (' ') (ou OBJECT) : Dans le même esprit que ce qui précède, on peut appliquer une ou des méthode (s) à un tag de type EMBED ou OBJECT de s'enrichir d'une structure arborescente située sur un serveur d'arbre externe ou non. Cela peut permettre notamment d'enrichir d'un arbre externe aussi bien un fichier Flash qu'une applet Java. L'enrichissement du marqueur originel peut se faire en procédant à un appel d'arbre après que soit appelée la source de l'EMBED (ou de l'OBJECT). L'enrichissement peut également concerner une concaténation de la chaîne de caractères constituant la valeur de l'attribut source SRC . Il peut s'agir alors, par exemple, d'ajouter une chaîne de caractères constituée d'une liste d'items du type paramètre= valeur , items séparés par le caractère & , ceci afin de spécifier à la page dynamique appelée, les paramètres qu'on désire lui transmettre. Nous pouvons également envisager la possibilité d'associer une unique structure arborescente à un ensemble de bandeaux distincts figurant sur une même page Web. Ainsi, cette unique structure arborescente sera stylisée afin de permettre à l'internaute de naviguer, grâce à un seul tableau de bord présent sur sa page, à travers les fonctionnalités offertes par l'ensemble des bandeaux publicitaires présents sur la page qu'il consulte. La phase de développement de Rich-Word, illustrée figure 20, se compose de trois interfaces distinctes : # L'interface Régie RI: L'utilisateur de l'interface régie (en général la régie qui gère les espaces publicitaires pour le compe de sites Web par l'intermédiaire de son trafficker) commence par entrer un mot de passe l'identifiant, puis inscrit un site Web dont elle assure la gestion des espaces publicitaires en indiquant son URL (ici le site dont l'URL est : PS~i2j2). R2: Lorsque le trafficker clique sur le bouton OK, l'URL PS~i2j2 est mémorisée dans la base de données des sites Web (PS). R3: Le click sur le bouton OK a également conduit à attribuer et présenter un mot de passe dédié au site inscrit par le trafficker de la régie. R4 : Le trafficker prend connaissance dudit mot de passe R5 : Le trafficker communique, par exemple par email, ledit mot de passe au Webmestre du site PS~i2j2. # L'interface Agence Al: L'utilisateur de l'interface agence (en général l'agence qui gère les achats d'espaces publicitaires pour le compte d'un annonceur par l'intermédiaire de son trafficker) commence par entrer un mot de passe l'identifiant. A2: Elle choisit ensuite un site Web dans la liste déroulante "URL Site Web" qui lui présente l'ensemble des URL des sites Web de la base de données PS, constituée des sites Web qui ont, indépendamment, renseigné l'interface de développement qui leur est dédiée. Ici elle choisit l'URL PS~i2j2. A3: L'agence indique, dans le champ "Mot(s)" prévu à cet effet, le (ou les) mot(s) sur lequel (lesquels) elle désire communiquer sur le site qu'elle a sélectionné. Ici, elle sélectionne le mot "Web", indiquant ainsi qu'elle désire communiquer sur le mot "Web" sur la page Web PS~i2j2. A4: L'agence sélectionne un des annonceurs dont elle assure la gestion. Elle sélectionne ici l'annonceur AD~i1j1 par le biais de la liste déroulante "Annonceur". A5: Le choix de l'annonceur provoque l'affichage, dans la liste déroulante "Arbre" de l'ensemble des structures arborescentes de l'annonceur AD~iljl . L'agence sélectionne un des arbres présentés dans cette liste déroulante. Elle choisit ici l'arbre noté T~iljlk. # L'interface Webmestre Wl: Le Webmestre entre le mot de passe que lui a communiqué la régie dans le champ "Mot de passe" prévu à cet effet. W2: ceci a pour effet d'indiquer, à partir de la base de données PS, l'URL PS~i2j2 du site du Webmestre. W3: Dans le champ "répertoire", le Webmestre indique, sous la forme d'une URL relative, la portion du site dont les pages sont les espaces publicitaires que la régie a en charge de gérer pour le Rich-Word. W4,W5: Lorsque le Webmestre clique sur le bouton OK, chacune des pages Web incluses dans le répertoire susmentionné, sont agrémentées d'un code JavaScript permettant, lorsque la page est consultée, d'aller rechercher les structures arborescentes correspondant aux mots achetés sur cette page. W6 : la nouvelle page est enregistrée à l'Url de l'ancienne. La diminution de l'intrusion correspond à une non-intervention du Webmestre. On peut rendre la phase de développement encore moins intrusive en permettant au Webmestre de ne pas y intervenir. Il suffit, pour ce faire, d'enrichir les marqueurs originels des bandeaux publicitaires d'un appel au script serveur "searchWord.jsp" qui requête la base de données RW. Ce procédé peut également s'étendre aux bandeaux publicitaires qui ne sont pas des Rich-Banner. Ainsi, il n'est pas nécessaire de modifier les pages Web que la régie désire mettre à disposition des agences pour la réservation de mots, dans la mesure où le tag y figure déjà par le biais des bandeaux publicitaires dont les marqueurs ont été enrichis de l'appel au serveur de RichWord. La phase de production du Rich-Word est illustrée figure 21. Cette phase de production du Rich-Word comprend les étapes suivantes : 1 : L'internaute consulte une page Web du site PS~i2j2. 2 : La code, inséré dans cette page au cours de la phase de développement, permet de requêter une page Web dynamique distante searchWord.ext , en lui donnant pour valeur l'URL de la page courante. 3 : Ladite page dynamique importe la liste des mots réservés pour cette page, à l'occasion de la phase de développement. 4 : Le texte de la page Web courante est parcouru à la recherche des mots réservés, ce qui détermine une nouvelle liste, dite liste restreinte 5 : Est importé, à partir du serveur d'arbre, l'ensemble des structures arborescentes coïncidant avec les mots de la liste restreinte. 6 : Modification du DOM de la page Web courante par intégration desdites structures arborescentes. Dans le cas de Rich-Word, l'élément est un mot. L'idée de Rich-Word est de permettre à une agence de réserver, sur une page Web donnée, un ensemble de mots pendant une certaine période. Les pages Web sont aujourd'hui le plus souvent dynamiques, si bien que l'on ne peut prévoir le contenu de la page Web avant que les champs texte, qui font appel dynamiquement aux champs d'une table d'une base de données, ne soient remplis du texte qu'ils extraient de cette base. La figure 22 résume le principe de l'appel dynamique de texte à partir d'une base de données. La page Web est constituée d'un certain nombre de n#uds Texte TNi. Certains de ces n#uds texte font appel, par le biais d'un marqueur , à une base de données. A cet effet peuvent être utilisées diverses technologies SSI (serveur side include): asp, php, cfm, jsp ... Le marqueur effectue donc une requête (Request) sur une base de données, requête dont le résultat (Response) est affiché à la place dudit marqueur. Ainsi, si l'élément est le mot, nous devons prendre en compte le fait que cet élément est stocké initialement dans le champ d'une table d'une base de données. Ce n'est qu'une fois que les contenus définitifs des n#uds texte ont été intégrés, de cette façon, au contenu de la page Web, que l'on est en mesure de confronter l'ensemble des contenus des n#uds texte à l'ensemble des mots qui ont été réservés par les agences pour cette page à des fins de communication. La figure 23 en montre le principe. A la fin du chargement de la page, et donc une fois que l'ensemble des n#uds texte TNi ont été résolus, une requête est adressée à la base de données RW afin d'obtenir l'ensemble des mots réservés par les agences pour cette page Web : liste est notée WordList. Un processus client génère ensuite une liste restreinte E qui est l'intersection de WordList et de l'ensemble des mots contenus dans les n#uds texte Ti. E est donc constitué d'un ensemble de mots ej, un mot ej ayant à la fois été réservé par une agence pour cette page Web et ayant été importé d'une base de données dans un champ d'une table à l'occasion du chargement de la page dynamique: E={e}. Cet ensemble E est envoyé en paramètre d'un processus visant à extraire, de la base de données du serveur d'arbre, l'ensemble T={tj} des structures arborescentes tj associées aux ej. La définition de la structure arborescente se fait indépendamment du fait que l'on soit dans le cas de Rich-Word ou de Rich-Banner ou autre. Dans le cas de RichWord, l'élément est un mot. La définition de l'élément consiste en la création du texte contenant le mot-élément, texte enregistré dans le champ d'une table d'une base de données. Dans le cas de RichWord, le marqueur originel, constitué de la page Web contenant l'ensemble des tags , a un lien avec les éléments dans la mesure où ces tags permettent de charger dynamiquement les TNi qui contiennent les éléments. La différence de fond entre RichWord et RichBanner réside dans le fait que l'étape d'enrichissement consiste ici en le stockage de l'association de l'élément (ici le mot) et de la structure arborescente (ainsi que de son moyen de déploiement). Il n'y a pas, dans le cas de Rich-Word, d'enrichissement d'un marqueur dans une phase de développement. Il n' y a qu'un tag à mettre dans la page numérique. Par contre, dans le cas de Rich-Banner, le marqueur originel contient une référence à un mécanisme de choix d'élément et l'enrichissement consiste à lui adjoindre une référence à un mécanisme de création dynamique d'arbre associé à l'élément. La figure 24 illustre la notion d'association dans le cas du Rich-Word. Cette figure peut cependant également s'appliquer au cas où le mot est un élément d'un autre type. Rich-Word s'applique autant aux mots contenus dans les pages Web qu'aux mots contenus dans le code source des graphismes vectoriels, dont les cartes géographiques vectorielles, puisque lesdits graphismes stockent explicitement lesdits mots dans leur code source. Une application possible de Rich-Word concerne l'e-publicité par la faculté d'acheter un (des) mot (s) sur une page Web, ceci pour une durée déterminée, et de déployer des menus adaptés à ce (ces) mot(s) et relatifs, par exemple, à des offres de service. - Une autre application possible concerne l'elearning par la faculté de fournir des explications détaillées et structurées, textuelles et/ou multimédia, à des mots de pages Web ou de graphismes vectoriels. Une autre application concerne les encyclopédies par la faculté d'associer des mots, contenus dans une page Web ou un graphisme vectoriel, aux explications détaillées et structurées, textuelles et/ou multimédia issues d'une encyclopédie numérique, éventuellement en ligne. - On peut également utiliser Rich-Word à des fins de traduction de mots, contenus dans une page Web ou un graphisme vectoriel, en s'appuyant sur des dictionnaires numériques, éventuellement en ligne. Cette liste d'applications possibles est non exhaustive. Les principes de Rich-Image sont illustrés figures 25 et 26. On considère une image sur laquelle figure un ensemble de m zones sensibles représentées par les polygones Pk. Le polygone Pk a n(k) sommets dont les coordonnées sont notées xi, yi. Lorsque l'on clique sur le polygone Pk on accède à la page Web cible~k.ext où l'extension ext peut appartenir, par exemple, à l'ensemble suivant : html, xml, asp, php, cfm, jsp... Le code HTML de cette image, avec ses zones sensibles, est le suivant : Une modification du code HTML consistant à donner, pour valeur des attributs "href" des balises "AREA" une expression du type "javascript: [code javascript de menus] " donne, au lieu d'un appel à une page Web, le déploiement d'un menu. La phase de développement de Rich-Image va ainsi consister à travailler à partir du marqueur originel, constitué par la tag IMG, afin de l'enrichir, par ajout d'un tag MAP définissant l'ensemble des zones sensibles déployant les menus. A la différence de Rich-Banner et de Rich-Word, la phase de développement intègre un travail graphique consistant à dessiner sur l'image même l'ensemble des zones sensibles desquelles on compte déployer les structures arborescentes. L'interface de développement invite, dans un premier temps, l'utilisateur à coller le marqueur originel dans le champ "marqueur". L'utilisateur dessine ensuite une zone sensible sur l'image qu'il a importé afin qu'elle apparaisse sur la page de l'interface. Puis il valide cette zone sensible en cliquant sur le bouton "Association arbre", ce qui entraîne l'ouverture d'une fenêtre ("choix d'un arbre et stylisation") reprenant en grande partie l'interface de développement de la Rich-Banner. L'utilisateur définit alors un arbre stylisé pour la zone sensible qu'il vient de dessiner, en procédant comme s'il attribuait un arbre stylisé à un bandeau publicitaire. Chaque arbre stylisé est sauvegardé dans la base de données des structures arborescentes (El). Après validation (clic sur le bouton "OK"), la fenêtre disparaît, lui donnant la possibilité de dessiner d'autres zones sensibles auxquelles il associera des arbres stylisés (E2). Au fur et à mesure du déroulement de ce processus, le marqueur originel est progressivement enrichi, le nouveau marqueur étant en mémoire dans le DOM de la page Web de l'interface de développement. Une fois cela réalisé, l'utilisateur clique sur le bouton de validation (bouton "OK") (SI), ce qui entraîne la mise à disposition du marqueur enrichi dans le champ "marqueur", de telle manière que l'utilisateur puisse le copier pour le transmettre aux serveurs de régie qu'il choisira. La phase de production a une particularité essentielle : après que le marqueur enrichi ait fait appel à l'image par le biais de la balise IMG, il sollicite le serveur d'arbre autant de fois qu'il y a de balises AREA imbriquées dans la balise MAP, c'est-à-dire autant de fois qu'il y a de zones sensibles associées à une structure arborescente. Quant à la cascade de requêtes conduisant à appeler le marqueur enrichi, il peut s'agir, par exemple, d'une simple page Web incorporant ce marqueur. L'image peut également être, par exemple, un bandeau publicitaire, auquel cas, ledit bandeau sera acheminé vers la plate-forme cliente de l'internaute suivant le processus classique dont nous avons déjà fait mention, à savoir la tag publicitaire, suivi du tag agence et enfin de l'appel au serveur de contenu. Ainsi, on peut concevoir d'adjoindre des zones sensibles sur des bandeaux publicitaires existants, zones sensibles auxquelles on associe des structures arborescentes stockées sur un serveur d'arbre indépendant. On ajoute ainsi l'interactivité, non plus à l'extérieur de la bannière mais au sein même de l'espace publicitaire. Un cas particulier de Rich-Image consiste à naviguer d'images en images par le biais des zones sensibles, c'est-à-dire de permettre, à partir d'un click sur une zone sensible zsi de l'image A, d'atteindre une image B qui, elle-même, contient des zones sensibles dont la cible est une autre image. Cela peut effectivement se concevoir selon le procédé de la présente invention, dans la mesure où l'on considère la création d'une structure arborescente Ti réduite à une feuille contenant le code client (javascript par exemple) permettant d'atteindre l'image B. Cette structure arborescente Ti peut également ne pas se réduire à une feuille et présenter un ensemble d'images différentes Bjvers lesquelles naviguer à partir de l'image A. Les zones sensibles d'une image sont réalisées à partir de polygones fermés. La question se pose de savoir s'il est possible d'établir, sur une image, des zones sensibles à partir d'autres primitives géométriques que les polygones fermés, et ceci sans plug-in, c'est-à-dire en ne comptant que sur le navigateur natif. La solution passe par la possibilité de construire l'ensemble des primitives géométriques à partir de polygones fermés. Si cela est réalisé, il sera alors possible de construire n'importe quelle figure géométrique à partir de zones sensibles. Il s'agit donc d'établir un ensemble de correspondance sous la forme, par exemple de bibliothèques de script en javascript. La balise doit être utilisée avec la balise qui, elle, possède trois attributs : shape, coords et href. Nous nous intéressons ici à shape et coords. shape peut prendre trois valeurs - rect : Pour un rectangle - circle : Pour un cercle poly Pour un polygone c o o r d s Indique les coordonnées des coins supérieurs gauche et inférieur droit de la zone pour un rectangle rect - Indique les coordonnées de chaque angle du polygone si vous optez pour la valeur poly Indique les coordonnées du centre du cercle et la dimension du rayon de ce même cercle pour la valeur circle Les polygones ne posent bien sûr aucun problème puisqu'ils correspondent à la valeur "poly" de l'attribut "shape". Donc : carrés, rectangles, losanges, triangles, quadrilatères... ne posent pas de problèmes. Les cercles ne posent bien sûr aucun problème puisqu'ils correspondent à la valeur "circle" de l'attribut "shape". La droite (AB) (aussi bien que la demi-droite [AB) ou le segment [AB]) est représentée par le polygone ABA (triangle). L'ellipse est représentée par un polygone inscrit dans l'ellipse que l'on cherche à tracer. La polyline (ligne brisée) A1, ..., An est obtenue par le polygone A1, ... , An-1, An, An-1, ... , A1. La courbe (C) est obtenue par la polyline A1, ..., An dont les sommets sont répartis régulièrement sur la courbe (C) , et ceci suffisamment fréquemment. Le point est représenté par un cercle de petit diamètre. Et ainsi de suite. On peut donc ainsi concevoir notamment une équivalence entre le principe des zones sensibles d'une image en HTML et les plug-ins à vocation de graphisme vectoriel (SVG, Flash ...) . On note que, dans le cas du Rich-Geobject, et ce le plus souvent, il est préférable de faire en sorte que le serveur du support de consultation soit identique au support de l'élément, c'est-à-dire ici du serveur spatial. Il est effectivement nécessaire que l'élément, afin d'être correctement affiché, subisse les mêmes types de traitement que ceux appliqués au support de consultation (la carte géographique). Ces traitements sont du domaine particulier des SIG (Systèmes d'Information Géographique). Il s'agit notamment des agents intelligents en vue du stockage puis de l'extraction des données stockées selon une indexation spatiale, du clipping évitant tout débordement graphique, des transformations permettant une conversion en mode vectoriel de données structurées par exemple en GML (Geography Markup Langage). La phase de développement de Rich-Geobject est assez proche de celle de Rich-Image dans la mesure où, de manière équivalent, elle intègre un travail graphique consistant à dessiner sur la carte même l'ensemble des primitives géométriques desquelles on compte déployer les structures arborescentes. S'il s'agit d'une carte géographique statique (image Gif par exemple), le problème se ramène à celui déjà traité de Rich-Image. Cependant, s'il s'agit d'une carte géographique dynamique, le problème se ramène, en partie, à celui traité dans le cas de Rich-Word, à savoir le stockage de l'association entre l'élément (ici la primitive géométrique) et la structure arborescente. Car ce n'est qu'une fois que ladite primitive fera partie intégrante du DOM de la page de la plate-forme cliente, qu'il sera possible d'effectuer la recherche de la structure arborescente qui lui a été éventuellement associée dans une phase antérieure de développement. Les primitives sont mémorisées par leur forme en coordonnées terrestres (latitude et longitude). Elles sont définies par la faculté offerte, par l'interface de développement à l'utilisateur, de tracer ces primitives en surimpression d'une carte géographique, puis de les associer à des structures arborescentes stylisées. L'interface de développement doit donc servir une carte géographique, issue d'un serveur spatial, et permettre à l'internaute de naviguer sur ladite carte, afin de positionner correctement ladite primitive géométrique. La phase de production reposera sur des cartes géographiques servies par le même serveur spatial que celui qui a servi au cours de la phase de développement, ceci afin d'éviter tout problème d'incohérence de données. La figure 29 indique un exemple d'interface de développement. La phase El correspond à l'enregistrement de l'arbre stylisé, tandis que la phase E2 fait revenir l'internaute à l'interface de départ. En phase SI sont enregistrées les coordonnées terrestres de la primitive géométrique, qu'il vient de dessiner sur la carte géographique, ainsi que l'association de cette primitive avec l'arbre stylisé qu'il vient de créer. La figure 30 représente un exemple de phase de production de Rich-Geobject, dans le cas d'un serveur spatial s'appuyant sur la technologie SVG. La requête de l'internaute conduit à afficher une carte géographique, ce qui conduit à afficher les primitives géométriques correspondantes, et ce qui conduit finalement à importer les arbres stylisés associés à ces primitives géométriques. Ainsi, dans la phase d'affichage, l'internaute effectue une requête spatiale à partir, par exemple, d'un click sur une carte géographique d'une page Web. Dans la phase de déploiement, la structure arborescente est graphiquement déployée à partir d'un survol par la souris d'un des éléments affichés. Enfin, dans la phase d'utilisation, l'internaute clique sur un des menus déployés et a accès à la minipage correspondante dans une pop-up, minipage éventuellement dynamiquement créée pour tenir compte des coordonnées géographiques correspondant à la position du curseur. Considérons une navigation de type nouvelle génération. La méthode traditionnelle de navigation peut être modélisée comme ceci : l' internaute navigue de pages Web en page Web par le biais de clics sur les liens desdites pages. Nous identifierons chaque étape de cette navigation par l'indice i=l, 2,3 ... A la ilème étape de la navigation, nous noterons A1 la page Web affichée dans le navigateur. L'internaute démarre sa navigation par l'ouverture du navigateur qui ouvre la page d'accueil dudit navigateur, page Web correspondant à l'indice i=l. Autrement dit la navigation démarre à la page A1. On définit la suite de pages Web (Ai) de la façon suivante : l' internaute passe de la page Ai à la page Ai+1 en cliquant sur un lien de la page Ai. Les liens d'une page Web sont repérés, dans son DOM (document object model), entre autres par l'attribut href des éléments A ou des éléments IMG . L'internaute clique sur le kième lien de la page Ai, klème lien dans l'ordre d'apparition dans le DOM de la page Air au sens d'un parsing défini au préalable. On peut donc définir la suite (ki) comme la suite constituée par les indices k choisis par l'internaute au cours de sa navigation de page en page. Autrement dit, à la ilème étape, l' internaute clique sur le kiième lien de la page Ai. A l'instar de la suite (Ai), la suite (ki) n'est pas connue a priori mais est construite au fur et à mesure de la navigation. Elle est donc connue seulement a posteriori, aucune règle mathématique ne permettant de la définir a priori puisqu'elle dépend des choix arbitraires de la navigation de l'internaute. On notera Ai (k) la page Web, cible du kième lien de la page Ai. A la iième étape de sa navigation, l' internaute clique sur le kiième lien de la page Ai, lien dont la valeur de l'attribut href est donc url (Ai (ki)). Par définition de la suite de pages Web (Ai) constituant la navigation de l' internaute, on a : Ai+1=Ai (ki). C'est une façon de dire que la page Ai+1 est la page cible du lien ki de la page Ai. Définissons maintenant une navigation Farnelienne : considérons une navigation traditionnelle (Ai), définie par la relation : Ai+1=Ai (ki). Considérons ensuite une page dynamique P située sur un serveur à l'url suivante : url(P). Par hypothèse, cette page P dynamique doit admettre, en entrée, au moins un paramètre nommé url , de type chaîne de caractères. On écrira : P(url, ...) Une navigation (A'i) est dite navigation Farnelienne d'origine (A1) et de paramètre P , ce que nous notons (A'i)=F[(Ai),P}, si, pour tout i, on a A'i(k)= P(url(Ai(k))...). Si on remplace k par ki, on a alors : A'i(ki) = P(url(Ai(ki)), ...) soit A'i+1 - P (url(Ai+1)). Dans le cas, par exemple, du kième lien constitué par un lien hypertexte, on avait, dans le DOM de la page Ai, l'élément suivant : Désormais, on a, dans le DOM de la page A'i, l'élément suivant : Une fois ki déterminé (à l'occasion du clic de l'internaute), Ai+1 l'est au même moment, puisque Ai+1=Ai (ki). La requête lancée est alors la suivante : url(P) ? url= 'url(Ai(ki))' & ... , c'est-à-dire : url(P) ? url= 'url(Ai+1)' & ... La nature de la page dynamique P conditionne le type de traitement effectué sur le serveur. Afin que la navigation (A'i) colle , autant que possible, à la navigation (Ai), on doit veiller à ce que soit respectée une contrainte supplémentaire relative à la nature de ce traitement. Dans notre cas, A'1+1 (résultat de la requête url(P) ? url= 'url(Ai+1)' & ... ) ne doit pas trop être éloigné de Ai+1. Nous imposerons donc, qu'au minimum, le klème lien de la page A' i+1 ait pour cible url(P) ? url= 'url(Ai+1(k))' & ... Ce qui entraîne que le traitement opéré par la page P contienne, au minimum, l'opération consistant, pour chaque lien k de la page Ai+1 (page accessible puisque son url est en paramètre de P), à extraire l'url url(Ai+1(k)), et à réaliser une concaténation de chaîne de caractères entraînant la création dynamique de la chaîne de caractères suivante url(P) ? url= 'url(Ai+1(k))' & ... , chaîne placée en page cible du kième lien de la page A'i+1. Une généralisation du concept de navigation Farnelienne peut consister à ne pas être contraint par une page dynamique P indépendant des indices i et k. Nous noterons alors Pik au lieu de P. Nous définissons ainsi, à partir de la navigation (Ai), une navigation (A'i), dite navigation d'origine (Ai) et paramétrée par la suite (Pik) . La suite (A'1+1) est alors définie par la relation de récurrence suivante : A'i+1 = Pik(url(Ai(ki)),...) ou encore A' i+1 = Pik(url(Ai+1)) Une navigation (Bi) est dite conditionnée s'il existe une navigation (Ai) et une suite de conditions (Ci), telles que, pour tout i, la page Bi corresponde à la transformation minimale de la page Ai, de telle façon que Bi vérifie la condition Ci. On notera : (Bi)=C[(Ai),(Ci)] On dira de la navigation (Bi) qu'elle est une navigation conditionnée par (Ci) et d'origine (Ai). Cas particulier : Dans le cas où la suite (Ci) est constante et vaut C, on dira, par abus de langage, que (Bi) est conditionnée par C. La condition C, que l'on suppose être vérifiée par Ai, page actuellement affichée dans le navigateur, est dite se propager de Ai à Ai+1 si, à l'issue de la transition conduisant à l'affichage de Ai+1, elle est vérifiée par Ai+1. Par définition d'une navigation (Bi) conditionnée par la condition C, ladite condition C doit être vérifiée pour tout i supérieur ou égal à 1. Pour que cela soit réalisé, elle doit être vérifiée pour i=l et doit se propager de Ai à Ai+1 (ceci pour tout i supérieur ou égal à 1). Pour que le procédé de propagation de la condition C soit effectif, on doit tenir compte non seulement de la propagation de ladite condition C mais aussi de la propagation des moyens de cette propagation. Un moyen de réalisation d'une telle propagation consiste à faire en sorte qu'il existe un fichier, appelé par convention script distant , incluant un code interprétable par la plate-forme cliente, tel que, pour tout i, soient vérifiées les deux contraintes suivantes : # Ai contient une référence au script distant Un cas particulier est celui du script distant dont le langage est le javascript, et que nous noterons sd.js , ladite référence pouvant alors s'exprimer de la façon suivante : Dans le cas particulier précédent, il s'agira de l'instruction suivante : javascript : sd(url(Ai(k))) Nous avons, jusqu'à présent, mentionné la notion de propagation de la condition C de i à i+1. Il est bien sûr nécessaire, afin qu'une telle propagation puisse exister, que la première page A1 d'une telle navigation (Ai) vérifie ladite condition C, autrement dit qu'il y ait un début à cette propagation. La solution va consister, ici, à faire en sorte qu'une telle navigation démarre dès l'ouverture du navigateur. Pour cela, la solution consiste à redéfinir la page d'accueil du navigateur, que nous noterons Ao, sans pour autant imposer à l'internaute de voir, à l'ouverture du navigateur, une autre page que celle qu'il a l'habitude de voir en premier, page que nous noterons ici A1. Autrement dit, il va s'agir de définir une nouvelle page d'accueil Ao qui effectuera un traitement puis redirigera vers la page A1. Ledit traitement aura pour finalité de faire en sorte que la page A1 vérifie la condition C, car si cela est le cas, il en sera donc de même de la page A2 puis de la page A3 et ainsi de suite, du fait de la propagation de ladite condition. Il s'agit d'un problème équivalent au principe connu de mathématiques, dit de récurrence . Si on note Pi la propriété suivante : (Pi) La page Ai vérifie la condition C Et si l'on suppose que : # la propriété P1 est vraie, # Pour tout i supérieur ou égal à 1, (Pi est vraie) entraîne que (Pi+1 est vraie) Alors, conformément au principe de récurrence, on peut dire que : pour tout i supérieur ou égal à 1, (Pi est vraie). Ceci est une autre façon de dire que quelle que soit la page atteinte au cours du processus de navigation de l'internaute, celle-ci vérifie la condition C. Le tout est donc de faire en sorte que la page Ao se redirige vers A1 de telle manière que P1 soit vraie, c'est-à-dire que A1 vérifie la condition C. L'internaute définit la page qu'il verra en premier (A1) par le biais d'un site Web dédié et non plus directement par le navigateur. Une fois cette page A1 renseignée à l'aide d'un champ texte d'un formulaire dudit site Web dédié, la validation dudit formulaire entraîne la création d'une page dynamique vérifiant la condition C ainsi que les moyens de sa propagation, et se redirigeant automatiquement vers la page A1. La validation du formulaire entraîne également la modification des paramètres du navigateur en attribuant comme page d'accueil de celui-ci ladite page dynamique Ao. Nous dirons de la navigation Farnelienne (A'i)=F[(Ai),P] qu'elle est une navigation d'élément permanent ep , si c'est une navigation conditionnée par la condition C définie par le fait que, pour tout i : Le DOM de A'inclue un fragment identifié par la chaîne de caractères ep , l'interprétation de ce fragment par le navigateur correspondant à la représentation dudit élément permanent sur la page affichée dans le navigateur. Un exemple de fragment est le calque suivant : ... code HTML ... (Nous considérerons, par la suite, être dans ce cas particulier). Ledit fragment est posté pour être récupéré par la page dynamique de la navigation Farnelienne. La propagation de ladite condition C consiste à propager un fragment de code identifié de façon permanente de page en page, ainsi que de propager le moyen de cette propagation. Afin de différencier le cas particulier de la condition de l'élément permanent d'une condition plus générale, nous nommerons ep le script distant et ep() une fonction définie dans ledit script distant. Un cas particulier est celui du script permanent exprimé en javascript, que nous noterons ep.js , ladite référence pouvant alors s'exprimer de la façon suivante : Par définition de la suite (ki), l'internaute clique sur le kiième lien de la page Ai, ce qui, par hypothèse, appelle la fonction ep(url(Ai(ki . Étudions un principe possible de fonctionnement d'un tel appel : # cette fonction crée dynamiquement un formulaire contenant un champ texte (élément de type input ), dont l'attribut name a pour valeur ep , qui permet de poster l'élément , ceci grâce à la méthode document.getElementById( ep ) qui permet de repérer cet élément. # La fonction donne ensuite, en valeur de l'attribut action du bouton submit dudit formulaire, la chaîne de caractères correspondant à la requête suivante : url(P) ? url=url(Ai(ki)), où Ai(ki) est la chaîne de caractères passée en paramètre de la fonction ep . # Enfin, la fonction simule un clic sur le bouton submit du formulaire, ceci grâce à l'instruction submit.click() , ce qui a pour conséquence d'envoyer ladite requête accompagnée du fragment correspondant à l'élément permanent dans l'état dans lequel il était au moment du click de l'internaute sur un des liens de la page Ai. Dans le cadre de la technologie XML, nous pouvons considérer que la page P est un fichier XML associé à une feuille de style XSLT que nous noterons Q ; page dynamique est alors notée : PQ. La page PQ vers laquelle est orienté l'internaute est donc le résultat d'un processus XSLT transformant la page Ai+1 en A'i+1, ce que l'on peut noter sous la forme . A'i+1=PQ(Ai+1). La page PQ commence par charger dans son DOM la page Ai+1=Ai(ki), ceci grâce à l'url dont la chaîne de caractères est explicitement écrite en paramètre de la requête url(PQ?url(Ai(ki))). Détaillons maintenant la transformation t transformant Ai+1 en A' 1+1 (A'i+1=t(Ai+1)) : Une fois la page Ai+1 chargée dans le DOM de la page PQ, cette dernière va parser (traverser) le DOM de la page Ai+1 à la recherche des occurrences de liens (par exemple en recherchant les éléments ayant un attribut href ) . Pour chaque lien ainsi trouvé, elle analyse la chaîne de caractères constitutive de la valeur de sa cible (par exemple la valeur de l'attribut href ). Si ladite chaîne de caractères commence par l'expression javascript , aucune modification n'est apportée. Si ce n'est pas le cas, cela veut dire que la valeur de l'attribut href du kième lien de la page Ai+1 est de la forme url (Ai+1 (k)). Le processus XSLT modifie alors la valeur de cet attribut par concaténation dynamique d'une chaîne de caractères afin que la nouvelle valeur soit : javascript : ep(url(PQ) ? url(Ai+1(k))) , ce qui permet de faire en sorte que la deuxième contrainte de conditionnalité soit vérifiée par la page A' 1+1 Elle s'est ainsi bien propagée de i à i+1. Il suffit donc qu'elle soit vérifiée pour i=l pour que, se propageant ainsi, elle le soit pour tout i supérieur ou égal à 1, conformément au principe mathématique de raisonnement par récurrence (Voir chapitre précédent). De la même manière, la première contrainte de conditionnalité se propage de i à i+1 par la simple capacité du processus PQ à générer le code suivant : dans la nouvelle page affichée. La première condition de l'élément permanent s'est propagée de i à i+1, puisque le formulaire dynamiquement créé, a posté le fragment identifié par ep , de telle manière qu'il soit récupéré dans la nouvelle page af f ichée . Quant à la deuxième condition de l'élément permanent, elle s'est propagée de i à i+1 puisqu'il s'agit d'une fonctionnalité incluse dans la fonction ep(), à laquelle fait référence la nouvelle page affichée du fait de la propagation des deux contraintes de conditionnalité. Le principe de Rich-Miniportail est de permettre à un internaute de naviguer sur Internet tout en ayant à portée de souris son portail personnalisé qui le suit de page en page . L'utilisation de Rich-Miniportail se fait conformément aux principes inhérents à la présente invention, notamment quant à la capacité de consulter et agir sur le miniportail sans quitter pour autant le site de consultation. Rich-Miniportail est, de ce point de vue, une avancée, en comparaison des barres d'outils des portails que l'internaute installe sur son ordinateur, dans la mesure où les boutons desdites barres d'outils entraînent la redirection vers une page Web autre que la page de consultation de l'internaute. D'autre part, Rich-Miniportail bénéficie de l'ensemble des fonctionnalités de Rich-Navigator, à savoir la capacité de créer des structures arborescentes personnalisées qui font appel à des services fournis par des sociétés externes : météo, dictionnaire, agenda.... Ainsi, l'internaute peut choisir un certain nombre de fonctionnalités n'existant pas nécessairement dans un portail donné, ou choisir un service équivalent mais autre que celui proposé dans le portail qu'il a l'habitude d'utiliser. Une fois définies des structures arborescentes personnalisées stockées sur un serveur d'arbre, RichMiniportail peut être aussi bien accessible par le biais des boutons d'une barre d'outil que par ce que nous appellerons dans ce qui suit un élément permanent . Le principe de l'élément permanent pour le Rich-Miniportail est le suivant : à l'occasion du chargement d'une nouvelle page dans un navigateur, ce procédé permet à un objet, qui occupait une position déterminée dans la fenêtre principale du navigateur ainsi qu'un état intrinsèque particulier, de figurer dans les mêmes position et état sur la page Web nouvellement chargée. Ce principe est illustré figure 31 (même position) et figure 32 (même état). Le procédé est le suivant : la solution consiste à écrire dynamiquement, dans le DOM (document object model) de la page Web en cours de chargement, un calque contenant les informations, relatives à l'élément permanent, récupérées à partir de la page précédente, conformément au procédé dit de navigation par élément permanent tel que décrit dans le chapitre précédent. Ce calque doit être positionné précisément dans la fenêtre principale du navigateur, ce qui nécessite de spécifier une valeur à l'attribut position :absolute ... C'est une des conditions de la navigation conditionnée. La mise en route du processus par l'internaute comporte les étapes suivantes : # Inscription de l'internaute sur un site Web spécifique L'internaute, afin de démarrer le processus de navigation par élément permanent, doit s'inscrire au préalable à un service en ligne disponible à l'aide d'une interface d'un site dédié. L'internaute s'inscrit en définissant son pseudonyme ainsi qu'un mot de passe. # Définition du type de l'élément Une fois inscrit, l'internaute accède à d'autres interfaces, lui permettant de choisir le type d'élément graphique qui sera affiché en surimpression des pages Web sur lesquelles il naviguera. # Création d'arbres L'internaute accède ensuite à une interface de création de structures arborescentes. Il utilisera, à cet effet, des services qu'il personnalisera en fonction de ses besoins spécifiques : agenda, dictionnaire, météo... Il bénéficie de l'ensemble des fonctionnalités déjà abordées en ce qui concerne la création de structures arborescentes : composition d'un arbre à partir de deux arbres ... # Création et activation d'un élément permanent La création d'un élément permanent consiste d'abord à associer un élément graphique à un arbre puis à stocker cette association dans la base de données d'un serveur. L'activation de cet élément permanent consiste ensuite à cliquer sur un bouton de validation, qui a pour effet de donner à un booléen la valeur true spécifiant ainsi que cet élément doit être servi à l'ouverture du navigateur. # Définition d'une page d'accueil La définition d'une page d'accueil s'effectue de la même manière que pour l'enclenchement du processus de navigation conditionnée. Le procédé permettant d'enclencher la navigation par élément permanent est décrit plus haut. Lorsqu'un internaute recherche, par le biais d'un moteur de recherche, les occurrences d'un mot sur le Web, la recherche peut s'étendre à une recherche dans les contenus textuels des graphismes vectoriels ainsi que dans les structures arborescentes actives. Le graphisme vectoriel permet d'accéder au contenu textuel explicitement écrit dans le code source. On peut donc étendre la recherche des moteurs de recherche au contenu textuel des graphismes vectoriels (SVG, Flash ...) . Ceci s'applique, en particulier, au cas de la cartographie vectorielle. On peut, en effet, envisager une recherche par un moteur de recherche qui conduit, outre les résultats traditionnels (pages Web, images ...), à afficher les résultats des contenus textuels des cartes géographiques vectorielles. Par exemple, une recherche sur le mot Pruneau peut conduire à afficher une carte géographique automatiquement centrée sur la ville d'Agen, si une carte, par exemple au format SVG est présente sur le Web et mentionne, dans son code source, le mot Pruneau au niveau (latitude et longitude) de la ville d'Agen. Il se peut que le mot Pruneau soit stocké dans une base de données et non dans le code source du fichier SVG qui se crée dynamiquement en puisant les informations de ladite base de données. Dans ce cas, le problème est équivalent au problème de référencement des pages Web dynamiques dont certaines solutions ont été envisagées comme le fait de produire de pages statiques à partir des pages dynamiques et de les stocker sur un serveur Web. Réciproquement, on peut envisager un service géolocalisé permettant de restreindre géographiquement la recherche d'un moteur de recherche en fonction de l'endroit du clic sur une carte géographique. Ceci s'applique aussi au cas où la position géographique n'est pas obtenue à partir d'un clic sur une carte géographique mais à partir d'un GPS. De plus, RichWord n'est pas réduit à une utilisation sur une page Web mais également sur des cartes géographiques compte tenu de l'accès textuel aux mots de ladite carte. Les arbres activés peuvent, par exemple, être mis à disposition sur un serveur Web sous la forme d'une page statique. De cette façon, en faisant en sorte que ces pages soient référencées par les moteurs de recherche, lesdits arbres seront également accessibles à l'occasion de la recherche d'un mot sur un moteur de recherche. Une publicité sous forme d'une Rich-Banner bénéficiera ainsi d'une plus grande visibilité puisque également accessible par le biais des moteurs de recherche. L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet. REVENDICATIONS 1. Procédé d'enrichissement du contenu d'une page numérique dont le format permet la création de liens vers des objets informatiques, et dont la représentation s'affiche par le biais d'un support d'affichage après chargement de ladite page numérique sur un équipement informatique relié à un réseau de communication depuis au moins un serveur informatique, caractérisé en ce qu'il comprend : # une étape de définition d'au moins une structure arborescente constituée d'un code structuré représentant une arborescence dont les feuilles correspondent à des codes cibles, susceptible de présenter une information structurée par imbrications successive # une étape de définition d'au moins un élément constitué par un fichier informatique apte à représenter un objet multimédia; # une étape de création d'au moins un marqueur originel, constitué par un code incluant une référence à un desdits éléments ; # une étape d'enrichissement du marqueur originel consistant en la génération d'un nouveau marqueur substitué audit marqueur originel, ledit marqueur originel étant modifié à partir : du contenu du marqueur originel, d'une (de) référence (s) ladite (aux dites) structure (s) arborescente (s) et d'un moyen de déploiement de la représentation de ladite structure arborescente ; # une étape d'adjonction, dans la page numérique, d'un lien vers le marqueur enrichi ; # une étape d'affichage sur un équipement client de la représentation dudit marqueur enrichi conduisant à une représentation enrichie dudit élément ; # une étape de déploiement de la représentation de ladite structure arborescente dans le support d'affichage, après action d'un utilisateur sur la représentation enrichie dudit élément. 2. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite étape de définition d'une structure arborescente comprend une sous-étape de stockage d'une structure arborescente ou d'un mécanisme permettant de créer dynamiquement une structure arborescente en fonction de paramètres de contexte. 3. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 2, caractérisé en ce que le stockage a lieu sur un serveur dédié. 4. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 2, caractérisé en ce que le stockage a lieu en local. 5. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 2, caractérisé en ce que le stockage a lieu avec le marqueur originel. 6. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications 2 à 5, caractérisé en ce que le stockage est effectué sous forme de fichiers, ces fichiers étant des fichiers de format SGML ou d'un format dérivé du SGML, des fichiers de format XML ou d'un format dérivé du XML, des fichiers de format DHTML, des fichiers de format binaire, des fichiers de format précompilé ou des fichiers de format texte. 7. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications 2 à 5, caractérisé en ce que le stockage est effectué dans une base de données numérique, cette base de données numérique étant relationnelle ou objet. 8. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications précédentes, caractérisé en ce que ladite étape de définition d'une structure arborescente consiste en la création de cette structure arborescente. 9. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications 1 et 2, caractérisé en ce que ladite étape de définition d'une structure arborescente consiste en la modification d'une structure arborescente déjà existante. 10. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications 1 et 2, caractérisé en ce que ladite étape de définition d'une structure arborescente consiste en la composition d'une structure arborescente à partir d'au moins deux structures arborescentes déjà existantes, ces structures arborescentes n'étant pas nécessairement distinctes les unes des autres. 11. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 9, caractérisé en ce que ladite modification consiste en la suppression d'un n#ud de ladite structure arborescente déjà existante. 12. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 9, caractérisé en ce que ladite modification consiste en la création d'un nouveau n#ud de ladite structure arborescente déjà existante. 13. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 9, caractérisé en ce que ladite modification consiste en la modification d'un n#ud de ladite structure arborescente déjà existante. 14. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 9, caractérisé en ce que ladite modification consiste en le déplacement d'un n#ud de ladite structure arborescente déjà existante. 15. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 10, caractérisé en ce que ladite composition consiste en le rattachement d'un fragment ou de la totalité d'une des structures arborescentes déjà existantes à une autre structure arborescente déjà existante. 16. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que l'utilisateur est un automate. 17. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le moyen de déploiement est de nature logicielle. 18. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le moyen de déploiement est de nature matérielle. 19. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est un programme installé en local. 20. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est un navigateur web. 21. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est un plug-in associé à un navigateur web. 22. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est implémenté sur un système embarqué. 23. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est implémenté sur un ordinateur personnel. 24. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est implémenté sur une borne interactive. 25. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est implémenté sur un appareil de télévision interactive. 26. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le support d'affichage est implémenté sur un appareil nomade. 27. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un événement souris ou en un événement clavier. 28. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un signal sonore. 29. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un événement tactile. 30. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que l'action d'un utilisateur sur la représentation du marqueur enrichi consiste en un automatisme déclenché par le contexte. 31. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 30, caractérisé en ce que le contexte est la situation géographique physique de l'utilisateur. 32. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 30, caractérisé en ce que le contexte est un mot-clé. 33. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 30, caractérisé en ce que le contexte est la date. 34. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 30, caractérisé en ce que le contexte est la situation géographique telle qu'elle est désignée par l'utilisateur. 35. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 30, caractérisé en ce que le contexte est une contrainte prédéfinie à l'avance. 36. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite page numérique est un support de carte . 37. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite page numérique est un support de contenu multimédia ou textuel. 38. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite page numérique est un support d'objet informatique . 39. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite page numérique est une page statique ou dynamique écrite en DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 40. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite page numérique est une page statique ou dynamique contenant du code écrit en DHTML, XML, HTML, CHTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 41. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite page numérique est une page statique ou dynamique faisant appel à du code écrit en DHTML, XML, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 42. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite page numérique est une page numérique statique ou dynamique, mettant en #uvre une animation Flash. 43. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur originel est constitué d'un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. 44. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur originel contient un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 45. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur originel fait appel à un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 46. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur originel est un programme compilé ou pré-compilé, du code ASCII ou du texte. 47. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur originel est un fichier, ce fichier est un fichier multimédia, un fichier texte, un fichier de format SGML ou d'un format dérivé du SGML, un fichier de format XML ou d'un format dérivé du XML, un fichier de format DHTML ou un fichier de données. 48. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur enrichi est constitué d'un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript. 49. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur enrichi contient un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 50. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur enrichi fait appel à un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 51. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur enrichi est un programme compilé ou pré-compilé, du code ASCII ou du texte. 52. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ledit marqueur enrichi est un fichier, ce fichier est un fichier multimédia, un fichier texte, un fichier de format SGML ou d'un format dérivé du SGML, un fichier de format XML ou d'un format dérivé du XML, un fichier de format DHTML ou un fichier de données. 53. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite structure arborescente est réduite à une simple feuille. 54. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que lesdits codes cibles sont des références à des fichiers cibles constitués d'un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 55. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que lesdits codes cibles sont des références à des fichiers cibles contenant un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, CHTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 56. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que lesdits codes cibles sont des références à des fichiers cibles faisant appel à un code écrit en DHTML, SGML ou l'un de ses dérivés, XML ou l'un de ses dérivés, HTML, C-HTML, WML, PHP, ASP, CFM, JSP, SVG, Java, JavaScript, ou VBScript . 57. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que lesdits codes cibles sont des références à des fichiers multimédias, ces fichiers multimédias étant des fichiers sons, animations ou vidéos. 58. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 57, caractérisé en ce que lesdits fichiers multimédias sont diffusés sous forme de streaming. 59. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite représentation dudit marqueur enrichi est un ensemble de menus et sous-menus imbriqués. 60. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite représentation dudit marqueur enrichi est un ensemble de listes déroulantes distinctes. 61. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que ladite représentation dudit marqueur enrichi est un ensemble de zones sensibles d'un fichier multimédia. 62. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications précédentes, caractérisé en ce que les feuilles de ladite structure arborescente correspondent à des liens dynamiquement créés en fonction de conditions résolues au moment de la requête de l'utilisateur. 63. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications précédentes, caractérisé en ce que les feuilles de ladite structure arborescente correspondent à des liens statiques. 64. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications précédentes, caractérisé en ce que ladite structure arborescente est créée via une interface de création. 65. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 64, caractérisé en ce que ladite interface de création est accessible en ligne. 66. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 64, caractérisé en ce que ladite interface de création fait partie d'un logiciel installé sur le poste de l'utilisateur de ladite interface. 67. Procédé d'enrichissement du contenu d'une page numérique selon l'une des revendications précédentes, caractérisé en ce que ladite étape de définition d'une structure arborescente consiste à appeler une structure arborescente préalablement enregistrée sur un support d'enregistrement. 68. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 67, caractérisé en ce que ledit support d'enregistrement est un support amovible. 69. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le marqueur originel fait référence à un bandeau publicitaire. 70. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le marqueur enrichi fait appel dynamiquement aux structures arborescentes relatives aux mots dynamiquement chargés sur la page numérique. 71. Procédé d'enrichissement du contenu d'une page numérique selon la revendication 1, caractérisé en ce que le marqueur enrichi fait appel dynamiquement aux structures arborescentes relatives à l'intersection d'un contexte géographique et d'un contexte thématique chargés dynamiquement sur la page numérique. 72. Procédé d'enrichissement du contenu d'une page numérique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'étape d'affichage dynamique de la représentation dudit marqueur enrichi inclut des modifications dynamiques de la page numérique. 73. Architecture informatique multiserveurs, caractérisée en ce qu'elle comprend notamment : # un poste client appelant une page numérique dont le contenu est enrichi selon le procédé de la revendication 1 ; # un serveur d'éléments stockant des éléments ; # un serveur contenant des règles d'appel aux dites références vers lesdits éléments ; # un serveur dédié contenant les structures arborescentes ; # un serveur web contenant ladite page numérique. 74. Architecture informatique multi-serveurs selon la revendication 73, caractérisée en ce qu'elle comprend en outre un serveur contenant des références vers lesdits éléments et des règles d'appel vers lesdits éléments 75. Architecture informatique multi-serveurs selon la revendication 73 ou 74, caractérisée en ce qu'elle comprend en outre un deuxième serveur web contenant des fichiers cibles. 76. Architecture informatique multi-serveurs selon la revendication 73, caractérisée en ce que les éléments sont des pages de texte. 77. Architecture informatique multi-serveurs selon la revendication 73, caractérisée en ce que les éléments sont des figures géométriques ou des mots, en ce que le serveur web contenant ladite page numérique est un serveur spatial.