FR 3038090 A1 20161230 FR 1555807 A 20150624 L'invention concerne les dispositifs web, et en particulier les dispositifs permettant une interaction. Plus particulièrement, l'invention concerne le domaine de la cartographie sur Internet. La cartographie sur Internet a longtemps été limitée à la reproduction de cartes papiers sous forme d'images. Cela était imprécis et fortement consommateur en bande passante, et posait des problèmes de pertinence, puisque les images n'offraient pas de moyen simple de mise à l'échelle ni de personnalisation. Des acteurs importants des nouvelles technologies ont modifié cette situation en proposant des cartes sur Internet qui étaient plus légères, dont la mise à l'échelle est adaptative, et qui permettent à l'utilisateur de parcourir rapidement une carte donnée. Pour note, comme l'invention, ces solutions sont toutes de type « pur Web », c'est-à- dire qu'un client Web (un navigateur ou une application de smartphone) interagit avec un serveur pour obtenir les données, mais ne stocke rien en local, hormis du cache. Toutes les données proviennent du serveur, en temps réel sauf pour les données du cache. Cela est crucial car, compte tenu des bandes passantes actuellement disponibles, les contraintes sur ce qu'il est possible d'obtenir en termes d'effets visuels sont très fortes si l'on souhaite maintenir un affichage fluide. Ces mêmes acteurs ont rajouté sur ces cartes des couches (« layer » en anglais) d'information afin d'ajouter un peu d'information, comme l'emplacement de certains commerces ou monuments, etc. Cependant, il s'agit littéralement de couches au sens graphique du terme : la nature de l'interaction est limitée à l'affichage d'un texte, la zone cliquable permettant cette interaction est limitée à une zone de taille réduite choisie de manière arbitraire, et ne peut pas par exemple concerner un immeuble entier, ou un parc dans une ville. Des efforts ont également été faits pour apporter un peu de réalisme par l'ajout de vue en trois dimensions pour certains bâtiments. Mais là encore, il s'agit d'éléments purement graphiques, dépourvus d'interaction. 3038090 2 L'invention vient améliorer la situation. À cet effet, l'invention propose un dispositif interactif, comprenant une interface utilisateur pour définir des requêtes d'affichage comprenant au moins des données de localisation et des données d'affichage, une interface réseau agencée pour émettre une requête de données de pages Web en 5 correspondance d'une requête d'affichage, une mémoire pour recevoir des données de page Web correspondantes, et un interpréteur Web pour afficher une page Web à partir de données de page Web, lequel interpréteur Web comprend au moins un interpréteur WebGL et un moteur 3D agencé pour calculer, pour des données de page Web données comprenant des données de cartographie et des données d'objet, des données de faces 10 d'au moins un objet associé aux données d'objet, pour regrouper ces données de faces dans des données de blocs de face et transmettre les données de blocs de faces à l'interpréteur WebGL pour le calcul de données d'affichage en trois dimensions dudit au moins un objet en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les 15 données de bloc de face, l'interpréteur Web étant agencé pour permettre d'afficher des données de page Web à partir des données de cartographie et des données d'affichage en trois dimensions dudit au moins un objet. Ce dispositif est avantageux car il permet d'avoir une représentation d'une cartographie 20 en trois dimensions, avec autant d'objets en trois dimensions que nécessaire, chaque objet étant cliquable individuellement et permettant une interaction inconnue jusqu'alors. De plus, comme les données de face sont calculées côté client, il devient possible de transmettre une grande quantité d'objets en trois dimensions, ce qui permet de modéliser tous les immeubles d'une ville, mais également les arbres et autres détails 25 de voirie, ainsi que les réseaux qui permettent d'atteindre un degré de détail et d'interactivité jamais atteint tout en conservant un affichage fluide. Selon diverses variantes, le dispositif peut présenter une ou plusieurs des caractéristiques suivantes : 30 - la mémoire stocke uniquement des données de type cache, 3038090 3 - les données d'affichage comprennent des données de zoom, et les données de cartographie définissent un environnement géographique sensiblement centré sur un endroit désigné par les données de localisation, et dont l'étendue dépend des données de zoom, 5 - les données d'objet comprennent des données de bâtiment comprenant des données de localisation de bâtiment, des données de forme de toit, et des données de hauteur, - les données d'objet comprennent des données de relief comprenant des données de localisation, et des données d'altitude, - le moteur 3D calcule les données de faces par triangulation à partir des données 10 d'objet et des données de zoom, - l'interpréteur Web est agencé pour déterminer un identifiant de données d'objet d'un objet désigné par un utilisateur via l'interface utilisateur à partir de la correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face., 15 - le code du moteur 3D est reçu comme données d'affichage à l'initialisation du dispositif et/ou lors de mises à jour, - le moteur 3D agence les données de blocs de faces dans un objet de type Float32Array, et - le dispositif comprend des ressources matérielles dédiées à l'affichage. 20 L'invention concerne également un procédé d'affichage interactif comprenant les opérations suivantes : a. définir une requête d'affichage comprenant au moins des données de localisation et des données d'affichage, 25 b. émettre une requête de données de pages Web en correspondance d'une requête d'affichage c. recevoir des données de page Web correspondantes comprenant des données de cartographie et des données d'objet, et les transmettre à un interpréteur Web comprenant un moteur 3D et un interpréteur WebGL 30 d. calculer avec le moteur 3D des données de faces d'au moins un objet associé aux données d'objet, et regrouper ces données de faces dans des données de blocs de face, 3038090 4 e. transmettre les données de blocs de faces à l'interpréteur WebGL, en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face, pour faire calculer des données d'affichage en trois dimensions dudit au moins un objet, 5 f appeler l'interpréteur Web avec les données de cartographie et les données d'affichage en trois dimensions dudit au moins un objet pour afficher des données de page Web. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de 10 la description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels : - la figure 1 représente un diagramme schématique d'un dispositif selon l'invention, dans son environnement de fonctionnement, - la figure 2 représente un diagramme schématique d'une boucle de fonctionnement du 15 dispositif de la figure 1, et - la figure 3 représente un diagramme schématique d'une opération de mise à jour de la figure 2. Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de 20 caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas 25 d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses droits. La figure 1 représente un schéma générique d'un dispositif interactif 2 selon l'invention 30 dans son environnement. 3038090 5 L'exemple décrit ici trouve une application particulièrement intéressante dans le domaine de la cartographie en ligne. Cependant, l'invention trouve son application dans toute situation impliquant un affichage en trois dimensions impliquant une interactivité avec l'utilisateur dans un contexte « tout serveur », ou « tout flux (streaming en 5 anglais) », c'est-à-dire que toutes les données sont issues d'un serveur, le dispositif ne stockant rien localement (y compris le code JavaScript du moteur 3D dans l'exemple décrit ici) à part du cache. Cette application est particulièrement adaptée à un usage Web, mais pourra être utilisée sous forme d'application pour smartphones par exemple, dans un format autre qu'une page Web. Dans ce cas, l'application pourra stocker les 10 données de code du moteur 3D par exemple, mais ne visera toujours pas à stocker d'autres données que du cache, c'est-à-dire que les données stockées ne sont pas persistantes. Le dispositif 2 comprend une mémoire 4, un affichage 6, une interface utilisateur 8, une 15 interface réseau (non représentée) et un interpréteur Web 10. La mémoire 4 peut être tout moyen de stocker des informations : de la mémoire Flash, de la mémoire RAM, un disque dur, une connexion à un stockage déporté ou dans le cloud, etc. Dans le cadre de l'invention, la mémoire 4 sert à stocker les données en vue 20 du traitement. Comme mentionné plus haut, les données de la mémoire 4 n'ont pas vocation à être persistantes, sauf à servir de cache dont la durée de validité est programmée et limitée. En effet, l'invention vise une application temps réel où toutes les données sont obtenues du serveur, sans stockage local préalable. 25 L'affichage 6 peut être tout affichage classique du type écran, projecteur vidéo, lunettes à projection, etc. L'interface utilisateur 8 permet à l'utilisateur du dispositif 2 de choisir les paramètres d'affichage de la carte ainsi que l'emplacement qu'il souhaite visualiser. Les paramètres d'affichage peuvent porter de manière non restrictive sur la latitude et la 30 longitude, le niveau de zoom, l'angle du vue, l'orientation. Ces paramètres sont classiques dans ce type d'application. L'invention propose également d'autres paramètres d'affichage, dits de « personnalisation ». 3038090 6 En effet, dans les applications connues, il est possible d'activer ou de désactiver l'affichage de certains éléments. Cependant, il s'agit uniquement d'afficher ou de ne pas afficher les couches d'informations correspondantes. Il ne s'agit pas de permettre de personnaliser l'affichage d'un jeu restreint d'objets, par exemple. D'ailleurs, il n'est pas 5 possible de parler « d'objets » dans les applications de l'art antérieur. Il s'agit de cartographies simples, éventuellement munies d'affichages en trois dimensions, mais non individualisables. À l'inverse, l'invention permet de rendre chaque élément de la cartographie indépendant, comme objet informatique. 10 L'interpréteur Web 10 peut être réalisé par tout navigateur mettant en oeuvre l'HTML, le JavaScript et le WebGL. Comme on le verra dans ce qui suit, l'interpréteur Web 10 comprend un interpréteur WebGL et un moteur 3D (non représentés). Dans l'exemple décrit ici, l'utilisateur accède à la cartographie par le biais d'une page Web. Cette page Web contient à la fois du code HTML, du code JavaScript et du code WebGL. Le code 15 JavaScript définit le moteur 3D, qui reçoit des données d'objet à représenter sur la portion de carte requise par l'utilisateur, et transforme ces données d'objet en données de faces. Les données de face sont transmises à l'interpréteur WebGL qui interagit avec les ressources matérielles du dispositif 2 pour calculer les données à afficher à proprement parler. 20 Comme mentionné précédemment, toutes les données sont obtenues d'un serveur 12 qui comprend une mémoire 14 et un moteur 16. La mémoire 14 est similaire à la mémoire 4, sauf en ce qu'elle stocke toutes les informations utiles au fonctionnement du dispositif 2 (contrairement à la mémoire 4 qui stocke quasi-exclusivement du cache). 25 Le moteur 16 est un élément qui reçoit les requêtes de données de pages Web du dispositif 2. Comme on l'a vu plus haut, à partir des données reçues par l'interface utilisateur 8, le dispositif 2 définit une requête d'affichage de cartographie à partir des données de localisation et des données d'affichage. Ces données définissent ensemble 30 une zone géographique. Sur la base de cette zone géographique, le dispositif 2 émet une requête de données de page Web vers le serveur 12, et le moteur 16 sélectionne dans la 3038090 7 mémoire 14 les données de cartographie ainsi que les données des objets qui correspondent à cette requête. Dans l'exemple décrit ici, les données de cartographie de la mémoire 14 sont stockées 5 sous la forme de tuiles (« tiles » en anglais) en plusieurs niveaux de détails. Ainsi, chaque tuile se décompose en quatre sous-tuiles quand le niveau de zoom augmente, et inversement, etc. Dans l'exemple décrit ici, les données de cartographie contiennent pour chaque tuile la liste des objets qui lui sont associés. En variante, les données d'objets pourraient contenir des données indiquant les tuiles auxquelles ils sont 10 rattachés. Dans l'exemple décrit ici, l'identification des tuiles est implicite, c'est-à-dire que le dispositif 2 peut déterminer quelles sont les données de tuile à demander au serveur 12 via la requête de données de page Web. Ainsi, cette dernière est une pure requête de 15 ressources, et le serveur 12 ne développe aucune « intelligence ». En variante, la requête de données de page Web pourrait être plus abstraite et contenir les données de localisation et les données d'affichage, et le serveur 12 se chargerait via le moteur 16 de déterminer les données de tuile pertinentes. 20 Les données des objets comprennent, dans l'exemple décrit ici, des données permettant de définir de manière abstraite l'affichage tridimensionnel de ces objets. Ainsi, pour un bâtiment, les données d'objet comprennent des données définissant l'empreinte au sol, la forme de son toit, et des données de hauteur de bâtiment. Un bâtiment peut présenter plusieurs hauteurs. Ainsi, lorsque le moteur 3D calcule les données de face d'un 25 bâtiment, il procède en « élevant » un contour correspondant à l'empreinte du bâtiment au sol à la hauteur des données d'objet correspondantes, et en calculant les triangles définissant chacune des faces de l'objet ainsi défini. Une autre manière de voir cela est de considérer qu'un bâtiment est « extrudé » à travers son empreinte au sol sur sa hauteur. Pour un sol ou un relief, il est procédé de manière similaire : à partir des tuiles 30 des données de cartographie, un maillage du sol par triangulation est réalisé. Ce maillage peut être utilisé pour représenter des reliefs grâce à des données d'objet de type données de relief, qui comprennent des données de localisation permettant 3038090 8 d'indiquer la tuile auxquelles elles correspondent, et des données d'altitude pour indiquer la hauteur du relief. Lorsque des données de relief sont reçues, les sommets des triangles des tuiles correspondants aux données de localisation correspondantes sont élevés à la hauteur désignée par les données d'altitude correspondantes. Les objets 5 peuvent également être immatériels, et désigner par exemple une ligne de bus ou de métro, ou un réseau de distribution d'eau ou d'électricité etc. De manière avantageuse, mais optionnelle, en fonction de la requête de données de page Web, le moteur 16 peut sélectionner les données d'objets en fonction d'une valeur 10 indiquant leur taille. Ainsi, si le zoom est très lointain, le moteur 16 ne retourne que les détails dont la taille est pertinente compte tenu de la résolution de la carte reproduite. Et dès qu'un utilisateur zoome, le moteur 16 enverra les données d'objet dont la taille les a rendus pertinents compte tenu de la résolution recherchée. Cela présente l'avantage de permettre de contrôler la charge de téléchargement et de traitement côté dispositif, mais 15 également d'améliorer l'expérience visuelle : au fur et à mesure qu'un utilisateur zoome, le monde se précise sous ses yeux. La figure 2 représente un diagramme schématique d'une boucle de fonctionnement du dispositif de la figure 1. 20 Dans une opération 200, le dispositif 2 réalise l'initialisation de l'affichage de la cartographie. Pour cela, les données de localisation et les paramètres d'affichage sont obtenus à partir de l'interface utilisateur 8, et le dispositif 2 met en oeuvre l'interface réseau pour émettre une requête d'affichage vers le serveur 12 avec ces données. En 25 réponse, le serveur 12 émet des données comprenant le code du moteur 3D, ainsi que les données de cartographie et les données d'objet correspondantes. Dans les échanges suivants, le code du moteur 3D n'est plus transmis. Dans une opération 220, le dispositif 2 reçoit les données de cartographie et les données 30 d'objet, ainsi que le code du moteur 3D. Sur la base de ces données, l'interpréteur Web 10 affiche par exemple en priorité les données de cartographies, qui donnent à l'utilisateur une vue rapide du « fond de carte ». Dans le même temps, le moteur 3D 3038090 9 traite les données d'objet pour calculer les données de face correspondantes. Les données de faces de chaque objet sont regroupées, et entrées dans un bloc de données de face, au moyen d'un bloc mémoire de type tableau à valeurs sur 32-bits (en anglais « Float32Array ») utilisé par l'interface WebGL, ci-après Buffer32. Le Buffer32 est un 5 outil classique en WebGL qui sert à transmettre une requête de calcul de données d'affichage 3D à une ressource matérielle à partir de données de faces définies dans le Buffer32. L'interpréteur WebGL transmet le Buffer32 contenant toutes les données de face à la ressource matérielle du dispositif 2 pour calcul des données pour l'affichage en trois dimensions des données d'objet. Chaque Buffer32 peut contenir des données 10 relatives à 65536 sommets de triangles. Lorsqu'un Buffer32 est « rempli », le moteur 3D en instancie un autre, tout en préservant les correspondances entre les données de chaque Buffer32 et les objets auxquels elles correspondent. En variante, le Buffer32 pourrait être réalisé avec un autre type de tableau de valeurs. Les données de face peuvent comprendre des données définissant des sommets, des faces, ou encore des 15 informations de mapping de texture sur les triangles. Simultanément, l'interpréteur Web 10 conserve une correspondance entre les données de face regroupées pour chaque objet du Buffer32 et les identifiants des objets correspondants. Ainsi, si un utilisateur veut sélectionner un objet, il clique avec la souris 20 sur un emplacement de ce dernier à l'écran (ou un autre moyen de désignation d'un emplacement à l'écran comme l' évènement « onMouseOver » JavaScript). En réponse, l'interpréteur WebGL émet une requête de type rayon (« ray picking » en anglais), qui retourne la face dans le Buffer32 qui a été désignée par le clic, et, sur la base de cette correspondance, l'interpréteur Web 10 est capable de savoir quel objet a été cliqué ou 25 désigné, et d'offrir à l'utilisateur un menu d'options pour réaliser des requêtes spécifiques à cet objet ou à une classe d'objets lui correspondant auprès du serveur 12, ou encore afficher cet objet de manière particulière. En variante, d'autres méthodes que le ray picking pourraient être utilisées pour déterminer la face qui se trouve sous la souris (par exemple le rendu en un seul point de la scène avec colorisation des faces sur 30 la base de leur identifiant et identification de la face à partir de la couleur de ce point). Cette caractéristique est fondamentale pour deux raisons : 3038090 10 - la concaténation d'un ensemble considérable de données de face dans quelques Buffer32 permet de réaliser un affichage d'une grande quantité d'objets sans perdre en fluidité. Cela était impossible avant l'invention ; et - le maintien de la correspondance entre les objets et les données de face qui leur 5 correspondent dans le bloc de données de face permet de rendre les objets réellement interactifs. Avant, les prétendus « objets » étaient des points ponctuels, ou des images en trois dimensions non cliquables. Dans le cas des points, il était difficile de cliquer, et la zone 10 cliquable était sans rapport avec l'objet concerné. De plus, du fait de l'approche « couche de données superposée » associée, l'idée n'était pas de rendre les objets interactifs, mais de rajouter une couche d'information simpliste. L'invention permet au contraire de produire un nouveau type de carte dans laquelle 15 l'interaction est possible et intuitive : si l'on veut avoir un renseignement sur une ligne de métro ou sur un bâtiment, ou sur la végétation d'une rue, il suffit de cliquer n'importe où sur l'objet correspondant. Dans les cartes existantes, la plupart des détails étaient omis pour la seule raison qu'ils 20 représentaient une masse d'information impossible à traiter d'un bloc sans ralentir de manière excessive le téléchargement et/ou l'affichage. Grâce au passage au contexte « objet », les détails sont eux-mêmes des objets. Il est donc possible de choisir la priorité d'affichage des objets, les détails les plus précis, ou « moins utiles » pouvant être affichés en dernier, ou ne pas être affichés du tout. 25 De plus, le fait de transformer la carte, d'une collection de tuiles de fonds de carte juxtaposées, en un monde composé d'objets individuels génère une quantité conséquente de nouvelles applications inenvisageables précédemment. Par exemple, il devient possible de réaliser des applications immobilières ou de géolocalisation qui 30 fournissent une information rapide et pertinente. Dans ce dernier cas, on peut imaginer qu'un clic sur un hôpital permettra de connaître les spécialités qui y sont pratiquées, ou encore qu'un clic sur un bâtiment particulier indiquera quels soins particuliers sont 3038090 11 dispensés et/ou les chambres du ou des services concernés, de cliquer sur un banc particulier pour indiquer qu'il a été vandalisé etc. Et les autres détails environnants peuvent être priorisés de manière inférieure pour préserver l'expérience utilisateur en lui fournissant l'information qui l'intéresse en priorité. Il devient donc possible d'introduire 5 une quantité énorme de « couches d'informations » de manière simple dans des cartes, là où cela était précédemment impossible ou incommode du fait de l'utilisation de « layers » superposées et non directement liées à des objets individualisés. Enfin, dans une opération 240, le dispositif 2 met à jour l'affichage 6 en fonction des 10 entrées utilisateur via l'interface utilisateur 8. Ainsi, si l'utilisateur change de niveau de zoom, déplace la carte ou interagit avec l'un des objets, l'interpréteur Web 10 appelle le serveur 12 pour obtenir de nouvelles données et calcule les données modifiées en conséquence. La figure 3 représente un exemple de mise en oeuvre de l'opération 240. Dans une 15 opération 300, l'interpréteur Web 10 détermine les données de localisation associées au centre de la carte désigné par l'interface utilisateur 8. Ensuite, l'interpréteur Web 10 détermine les paramètres d'affichage comme l'angle de vue et le zoom pour déterminer une nouvelle zone qui doit être représentée par l'affichage. 20 Dans une opération 320, l'interpréteur Web 10 détermine la liste des tuiles correspondant à la nouvelle vue déterminée à l'opération 300 et ne demande au serveur que celles qu'il n'a pas déjà. En réponse, le serveur 12 retourne la liste des tuiles correspondantes. En variante, le serveur 12 peut conserver une liste des tuiles et objets déjà transmis et/ou considérés comme courants, et transmettre directement les nouvelles 25 données pertinentes. Enfin, dans une opération 340, l'interpréteur Web 10 procède aux mêmes opérations que pour l'opération 220 pour les données nouvellement obtenues, et met à jour si nécessaire les données déjà connues et affichées. 30 Par exemple, si un niveau de zoom a été changé, des informations plus fines concernant le relief sont reçues. La mise à jour de l'altitude d'un bâtiment déjà affiché peut être 3038090 12 réalisée par simple mise à jour de l'élévation dans la définition des données de faces de bâtiment dans le bloc de données de face. Ainsi, pour les objets déjà affichés, la mise à jour est aussi légère que possible et permet la construction d'une carte en 3D avec données n'arrivant que séquentiellement et dans le désordre. Toutes les optimisations présentées ci-dessus sont rendues possibles par le fait que l'invention met en oeuvre un contexte « objet » décrit plus haut, alors que cela n'était pas possible précédemment. REVENDICATIONS1. Dispositif interactif, comprenant une interface utilisateur (8) pour définir des requêtes d'affichage comprenant au moins des données de localisation et des données d'affichage, une interface réseau agencée pour émettre une requête de données de pages Web en correspondance d'une requête d'affichage, une mémoire (4) pour recevoir des données de page Web correspondantes, et un interpréteur Web (10) pour afficher une page Web à partir de données de page Web, lequel interpréteur Web (10) comprend au moins un interpréteur WebGL et un moteur 3D agencé pour calculer, pour des données de page Web données comprenant des données de cartographie et des données d'objet, des données de faces d'au moins un objet associé aux données d'objet, pour regrouper ces données de faces dans des données de blocs de face et transmettre les données de blocs de faces à l'interpréteur WebGL pour le calcul de données d'affichage en trois dimensions dudit au moins un objet en conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face, l'interpréteur Web (10) étant agencé pour permettre d'afficher des données de page Web à partir des données de cartographie et des données d'affichage en trois dimensions dudit au moins un objet. 2. Dispositif selon la revendication 1, dans lequel la mémoire stocke uniquement des données de type cache. 3. Dispositif selon la revendication 1 ou 2, dans lequel les données d'affichage comprennent des données de zoom, et les données de cartographie définissent un environnement géographique sensiblement centré sur un endroit désigné par les données de localisation, et dont l'étendue dépend des données de zoom. 4. Dispositif selon l'une des revendications précédentes, dans lequel les données d'objet comprennent des données de bâtiment comprenant des données de 3038090 14 localisation de bâtiment, des données de forme de toit, et des données de hauteur. 5. Dispositif selon l'une des revendications précédentes, dans lequel les données d'objet comprennent des données de relief comprenant des données de 5 localisation, et des données d'altitude. 6. Dispositif selon la revendication 3 et l'une des revendications 4 et 5, dans lequel le moteur 3D calcule les données de faces par triangulation à partir des données d'objet et des données de zoom. 10 7. Dispositif selon l'une des revendications précédentes, dans lequel l'interpréteur Web (10) est agencé pour déterminer un identifiant de données d'objet d'un objet désigné par un utilisateur via l'interface utilisateur (8) à partir de la correspondance entre certains au moins des objets associés aux données d'objet 15 et les données de faces qui leur correspondent dans les données de bloc de face. 8. Dispositif selon l'une des revendications précédentes, dans lequel le code du moteur 3D est reçu comme données d'affichage à l'initialisation du dispositif (2) et/ou lors de mises à jour. 20 9. Dispositif selon l'une des revendications précédentes, dans lequel le moteur 3D agence les données de blocs de faces dans un objet de type Float32Array. 10. Procédé d'affichage interactif comprenant les opérations suivantes : 25 a. définir une requête d'affichage comprenant au moins des données de localisation et des données d'affichage, b. émettre une requête de données de pages Web en correspondance d'une requête d'affichage c. recevoir des données de page Web correspondantes comprenant des 30 données de cartographie et des données d'objet, et les transmettre à un interpréteur Web comprenant un moteur 3D et un interpréteur WebGL 3038090 15 d. calculer avec le moteur 3D des données de faces d'au moins un objet associé aux données d'objet, et regrouper ces données de faces dans des données de blocs de face, e. transmettre les données de blocs de faces à l'interpréteur WebGL, en 5 conservant une correspondance entre certains au moins des objets associés aux données d'objet et les données de faces qui leur correspondent dans les données de bloc de face, pour faire calculer des données d'affichage en trois dimensions dudit au moins un objet, f appeler l'interpréteur Web avec les données de cartographie et les 10 données d'affichage en trois dimensions dudit au moins un objet pour afficher des données de page Web.