FR 2851389 A1 20040820 FR 0301829 A 20030214 La présente invention se rapporte à un procédé et à un dispositif de gestion de requêtes dans une architecture du type client-serveur. Depuis ces dernières années, le grand public a la possibilité d'échanger des données numériques à travers le réseau Internet. Plus qu'un phénomène de mode, Internet est devenu un outil sans précédent pour envoyer un message électronique et/ou obtenir des informations sur à peu près 10 n'importe quel sujet et ce quasiment en temps réel. Les premiers sites, communément appelés sites Web, permettaient de télécharger une application (ou une page au format HTML), et de la "jouer" (ou de la visualiser à partir d'un outil de navigation). De nombreuses évolutions ont été apportées tant au niveau des 15 formats de fichiers transférés qu'au niveau des protocoles de transfert. Concernant plus spécifiquement le format de fichier HTML, les pages Web sont devenues interactives, permettant ainsi à l'utilisateur de personnaliser la visualisation de ces pages et d'envoyer des requêtes au serveur qui héberge le site visité. De plus, ces pages sont devenues plus attrayantes depuis que ce 20 format permet l'encapsulation d'animations temporelles d'objets multimédia. Néanmoins, la taille des fichiers transférés, c'est-à-dire les fichiers qui contiennent une application ou une page HTML, doit être minimale car la bande passante du réseau Internet est toujours limitée à quelques kilo octets. De façon que le temps de téléchargement ne soit pas trop important, le format 25 HTML a été conçu pour permettre d'organiser de façon hiérarchique les données à transférer. Ainsi, en hiérarchisant ces données selon leur ordre d'utilisation par l'outil de navigation, il est possible de visualiser une page HTML ou de jouer une animation sans pour cela attendre que tout le fichier soit téléchargé. Cette propriété permet à l'utilisateur de naviguer plus aisément sur 30 un site. Pour les animations d'objets multimédia, un format de fichiers (SWF) a été défini qui permet de décrire des animations temporelles de données multimédia à partir de données vectorielles. Ainsi, la taille des fichiers HTML reste dans des proportions acceptables. De plus, ce format permet de jouer l'animation sans pour cela attendre que l'ensemble du fichier soit téléchargé. Pour ces deux raisons, ce format est largement utilisé pour inclure des 5 animations d'objets multimédia dans une page HTML et on commence à voir apparaître des sites conçus exclusivement avec des données "Flash" (nom communément employé pour désigner des animations résultant d'un fichier SWF). Dès qu'un utilisateur demande le téléchargement de données 10 multimédia à un serveur, ce dernier lui envoie un fichier qui comporte des données dites minimales. A partir de ces données, l'outil de navigation construit une page HTML et la visualise sur un écran. Dans le cas o cette page contiendrait une animation Flash, les données dédiées à cette animation sont interprétées par un "décodeur" Flash intégré à l'outil de navigation. Le fichier de données peut également comporter un jeu de commandes qui permettent de récupérer des données multimédia supplémentaires, une fois que le fichier est téléchargé. De plus, dans la plupart des applications, les données minimales permettent à l'utilisateur d'interagir avec le serveur pour pouvoir récupérer des informations supplémentaires. C'est 20 ce qu'on appellera par la suite des "requêtes". Comme on le verra plus loin, la présente invention peut s'appliquer à n'importe quel système de réception de données multimédia qui inclut des requêtes d'origines différentes. De façon générale, les requêtes sont de natures différentes. Elles 25 peuvent être prédictibles, dans le cas o elles seraient incluses dans le fichier téléchargé initialement et que les données récupérées, au travers de ces requêtes, sont nécessaires au bon déroulement d'une application (ou d'une animation). Ce jeu de requêtes est prédéfini par le concepteur de l'application ou de l'animation. D'autres sont imprédictibles, telles que les requêtes émises 30 par l'utilisateur. Enfin, une dernière classe de requêtes permet d'anticiper le pré-chargement (en anglais "pre- fetching") de données multimédia. En effet, dès lors qu'un utilisateur a téléchargé un fichier, on peut anticiper les futures demandes de cet utilisateur et pré-charger des données, de façon à répondre sans délai à ces besoins futurs. Ces requêtes ne sont généralement pas prédictibles, car elles évoluent selon les requêtes effectives de l'utilisateur et le déroulement de l'application (ou de l'animation). La plupart des systèmes de transmission de données multimédia ne sont pas confrontés au problème de gestion de requêtes de natures différentes car le format des données encapsulées dans le fichier ne fournit pas la possibilité de définir des requêtes de natures différentes. Seules les requêtes émanant de l'utilisateur sont gérées et parfois celles liées à l'application. 10 Néanmoins, ces systèmes ne gèrent pas plusieurs classes de requêtes à la fois. Le document US-A-6 442 658 divulgue un mécanisme qui gère un jeu de requêtes de façon qu'une animation Flash puisse se dérouler correctement. Le fichier SWF utilisé pour définir une animation Flash est décomposé en segments de données indépendants les uns des autres. Par exemple, un premier segment comporte des données vidéo et un second segment des données image. Lorsque la machine client reçoit le premier segment, le "décodeur" Flash doit s'assurer que les ressources nécessaires 20 pour jouer la vidéo, c'est-à-dire la mémoire disponible et le décodeur de données vidéo, dans le cas o les données du segment seraient codées, sont disponibles sur la machine client. Si le décodeur est présent sur la machine client, le segment est joué. Dans le cas contraire, le "décodeur" Flash extrait la localisation de cette ressource à partir du fichier SWF le plus souvent un lien 25 Internet sur un serveur - et envoie la requête à ce serveur. Une fois la réponse reçue, le décodeur vidéo est installé sur la machine client et le segment est joué. Ainsi, si plusieurs segments doivent être joués, la solution la plus triviale est de vérifier si toutes les ressources nécessaires pour jouer les 30 segments d'un fichier SWF sont disponibles sur la machine client. Dans le cas o certaines d'entre elles ne le seraient pas, il faut émettre des requêtes aux différents serveurs au travers des informations extraites à partir du fichier SWF. Néanmoins, cette solution n'est pas envisageable car elle demanderait trop de mémoire de stockage et des temps de téléchargement trop importants avant de pouvoir jouer le premier segment. Le document US-A-6 442 658 propose de résoudre ce problème en incluant un mécanisme de pré5 chargement de ces ressources. En effet, lorsqu'un segment est en train d'être joué, ce processus télécharge les données et les ressources du segment qui va être joué juste après. Une fois jouées, les données et les ressources sont supprimées de la mémoire de stockage, évitant ainsi une surcharge de cette mémoire. Le problème résolu par ce document consiste donc à définir le segment qui sera joué à la fin de l'exécution du segment courant. Pour cela, une priorité est associée à chaque segment. Cette priorité est la combinaison du temps nécessaire à la récupération des données et des ressources et de la probabilité que le segment soit joué juste après le segment courant. Le mécanisme décrit dans ce document ne gère qu'une seule classe de requêtes de pré-chargement. De plus, le jeu de requêtes considéré dans ce document est statique, c'est-à-dire qu'aucune nouvelle requête de préchargement n'est engendrée. La présente invention a pour but de remédier à cet inconvénient, en 20 permettant de gérer les requêtes de différentes classes et d'engendrer de nouvelles requêtes de pré-chargement au cours de l'exécution d'une application et en fonction du comportement de l'utilisateur. Dans ce but, la présente invention propose un procédé de gestion de requêtes d'au moins deux classes distinctes, portant sur des données 25 multimédia, échangées par un appareil de communication et au moins une source de données connectés par l'intermédiaire d'un réseau de communication, remarquable en ce que ce procédé comporte des étapes, effectuées au niveau de l'appareil de communication, de: - validation d'au moins une requête d'au moins une première classe 30 de requêtes, la validation tenant compte des données multimédia reçues à partir d'au moins une deuxième classe de requêtes; et - affectation dynamique d'une priorité à chacune des requêtes validées, suivant des caractéristiques des requêtes validées. L'invention permet ainsi, grâce à l'attribution de priorités aux diverses requêtes, de gérer des requêtes de différentes classes. L'étape de validation permet d'autoriser (ou non) momentanément l'envoi de chacune des requêtes. L'étape d'affectation dynamique permet de hiérarchiser les requêtes validées, de façon à récupérer les données les plus utiles à un instant donné. Selon une caractéristique particulière, le procédé comporte en outre 10 une étape de décision quant à la transmission d'au moins une requête validée, en fonction de la priorité affectée à cette requête. Cela permet de gérer l'envoi en continu des requêtes, de façon à optimiser l'utilisation de la bande passante du réseau. Selon une caractéristique particulière, ce procédé comporte en outre 15 une étape de mise à jour des requêtes d'au moins une première classe, la mise à jour tenant compte des données multimédia reçues à partir d'au moins une requête d'au moins une deuxième classe. En réponse à ces requêtes, des données sont reçues et mémorisées. L'analyse de ces données rend obsolètes certaines requêtes, 20 puisque les données sont déjà récupérées. Par ailleurs, de nouvelles requêtes peuvent être créées car de nouveaux besoins peuvent émaner de la part de l'utilisateur au travers d'une interface graphique. Enfin, selon les données reçues, certaines requêtes doivent être fusionnées, car considérées individuellement, elles ne permettent de récupérer qu'une infime partie des 25 données. Comme chaque requête possède un entête incompressible, il peut arriver que la quantité de données récupérées soit très faible par rapport à la taille des requêtes. Cette fusion de requêtes permet ainsi d'optimiser la bande passante du réseau en minimisant l'envoi de requêtes. L'étape de mise à jour permet la gestion de ces différents cas. Dans un mode particulier de réalisation, l'appareil de communication et la source de données sont connectés par une connexion de type HTTP. Les données peuvent par exemple être des animations Flash et/ou des données d'images comprimées suivant la norme JPEG2000. Les requêtes peuvent être associées à l'animation d'un objet et/ou à la réalisation d'un zoom ou d'un panoramique ou d'un changement de qualité sur une image et/ou à des interactions entre un utilisateur et une animation. Dans le même but que celui indiqué plus haut, la présente invention propose également un dispositif de gestion de requêtes d'au moins deux classes distinctes, portant sur des données multimédia, échangées par un appareil de communication et au moins une source de données connectés par 10 l'intermédiaire d'un réseau de communication, remarquable en ce que ce dispositif comporte: - un module de validation d'au moins une requête d'au moins une première classe de requêtes, la validation tenant compte des données multimédia reçues à partir d'au moins une deuxième classe de requêtes; et - un module d'affectation dynamique d'une priorité à chacune des requêtes validées, suivant des caractéristiques des requêtes validées. La présente invention vise aussi un appareil de communication comportant un dispositif tel que ci-dessus. L'invention vise aussi: - un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, permettant la mise en oeuvre d'un procédé tel que ci-dessus, et - un moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur conservant des 25 instructions d'un programme informatique, permettant la mise en oeuvre d'un procédé tel que ci-dessus. L'invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable et comportant des séquences d'instructions pour mettre en oeuvre un procédé tel que ci-dessus, lorsque ce 30 programme est chargé et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du dispositif de gestion de requêtes, de l'appareil de communication, des différents moyens de stockage et du produit programme d'ordinateur étant similaires à ceux du procédé selon l'invention, ils ne sont pas rappelés ici. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à 5 titre d'exemple non limitatif. La description se réfère aux dessins qui l'accompagnent, dans lesquels: - la figure 1 illustre de façon schématique un dispositif de transmission de données multimédia mettant en oeuvre la présente invention, dans un mode particulier de réalisation; la figure 2a illustre de façon schématique un exemple d'animation Flash; la figure 2b illustre de façon schématique des exemples d'actions sur une image au format JPEG2000; - la figure 3 est un organigramme illustrant les principales étapes 15 d'initialisation du mécanisme de gestion des requêtes conforme à la présente invention, dans un mode particulier de réalisation; - la figure 4 est un organigramme illustrant les principales étapes de la mise à jour du jeu de requêtes de pré-chargement conformément à la présente invention, dans un mode particulier de réalisation; - la figure 5 est un organigramme illustrant les principales étapes du mécanisme d'envoi des requêtes conformément à la présente invention, dans un mode particulier de réalisation; et - la figure 6 illustre schématiquement un dispositif mettant en oeuvre la présente invention, dans un mode particulier de réalisation. Le schéma-bloc de la figure 1 illustre l'architecture générale d'un dispositif de transmission de données numériques point à point entre une machine dite serveur et une machine dite client, mettant en oeuvre l'invention. Ce dispositif peut comporter des éléments électroniques et/ou comporter des éléments logiciels. Le dispositif représenté sur la figure 1 comprend une machine 2 dite client, qui est un appareil de communication, et une machine 1 dite serveur, qui constitue une source de données. Ces machines sont reliées par un réseau de communication 3 au travers d'une connexion. Selon un mode préféré de réalisation de l'invention, une connexion HTTP est utilisée. Néanmoins, l'invention peut être mise en oeuvre sur d'autres types de connexions. La machine client 2 peut, en variante, être reliée à plusieurs sources de données 5 du type de la machine serveur 1. De plus, nous considérons par la suite que la transmission des données s'effectue sans aucune perte d'information. La machine client 2 de la figure 1 comporte une unité 21 de stockage de données numériques qui mémorise temporairement les données numériques reçues. Une unité 22 de stockage de requêtes mémorise quant à 10 elle, à la fois les requêtes reçues par une unité 24 de réception de requêtes, et les requêtes émanant d'une unité 26 de gestion de requêtes, comme on le verra par la suite. L'unité 26 de gestion de requêtes est au coeur de l'invention. Le client 2 comporte aussi une unité 25 d'envoi de requêtes. La machine client 2 comporte également une unité 27 de réception 15 de données numériques, dont le rôle est de recevoir les données numériques émanant du serveur 1 et de les envoyer à l'unité 21 de stockage de données. De plus, la machine client 2 comporte une unité 23 de traitement de données numériques qui traite les données numériques stockées dans l'unité 21. Selon un mode préféré de réalisation de l'invention, l'unité 23 de traitement de 20 données prépare les données contenues dans l'unité 21 de stockage pour les visualiser sur un écran (non représenté sur la figure 1). Enfin, la machine client 2 comporte une unité 28 de commande qui contrôle le fonctionnement des diverses unités mentionnées précédemment. La machine serveur 1 de la figure 1 comporte une unité 10 de 25 réception de requêtes, qui réceptionne les requêtes émanant de la machine client 2. L'unité 10 de réception de requêtes envoie les requêtes à une unité 12 de traitement de requêtes, qui les traite. Selon un mode préféré de réalisation de l'invention, ce traitement consiste à récupérer les données numériques requises, à partir d'une unité 13 de stockage de données numériques, et à les 30 formater et les envoyer au travers d'une unité 11 d'envoi de données numériques. La machine serveur 1 comporte également une unité 14 de commande qui contrôle le fonctionnement des diverses unités mentionnées précédemment. Selon un mode préféré de réalisation de l'invention, une connexion HTTP est établie entre les machines client 2 et serveur 1. Pour cela, les unités 5 25 d'envoi de requêtes et 27 de réception de données de la machine client 2 et les unités 10 de réception de requêtes et 11 d'envoi de données de la machine serveur 1 implémentent ce protocole, de façon à pouvoir échanger des données. Selon un mode préféré de réalisation de l'invention, les données 10 numériques échangées sont de deux natures: des animations Flash et/ou des données d'image comprimées suivant la norme JPEG2000. Les animations Flash sont stockées dans des fichiers ayant une extension ".swf'. Par la suite, ce type de fichiers sera appelé SWF. Ces animations sont largement utilisées à l'intérieur des pages Web et même pour 15 définir complètement un site. De par leur format vectoriel, elles permettent l'introduction d'animations temporelles d'objets numériques dans les pages d'un site Web et ce tout en préservant une taille du fichier SWF réduite. Par la suite, nous considérons qu'une animation a été créée et stockée dans l'unité 13 de stockage de données de la machine serveur 1. En référence à la figure 2a, le fichier SWF 205 utilisé par la suite contient une animation temporelle d'un objet, c'est-à-dire des données d'image représentant l'objet lors de sa position initiale 201 jusqu'à sa position finale 202 selon la trajectoire 203, ainsi qu'un jeu de requêtes permettant de récupérer, à partir du serveur, des informations complémentaires nécessaires à la réalisation 25 de l'animation. Les requêtes associées à l'animation de cet objet composent une classe de requêtes appelée par la suite Ra. De plus, le fichier SWF contient une image 204 comprimée suivant le format JPEG2000. Ce format permet un accès aléatoire aux données image, c'est-à-dire que le train binaire est formaté de façon à pouvoir récupérer 30 plusieurs résolutions spatiales de l'image pour une même qualité et plusieurs qualités pour une résolution spatiale donnée. De même, il est possible de récupérer une partie de l'image à une qualité donnée. Le fichier JPEG2000 est stocké dans l'unité 13 de stockage de données de la machine serveur 1. Selon un mode préféré de réalisation de l'invention, la version basse qualité de l'image est incluse dans le fichier SWF. Lorsque l'animation Flash est jouée, l'utilisateur a la possibilité 5 d'effectuer des actions sur l'image JPEG2000 telles que décrites par la figure 2b. Selon un mode préféré de réalisation de l'invention, trois actions sont disponibles: un zoom, un panoramique (en anglais "pan") (dans le cas o la fenêtre de visualisation 207 de l'animation serait plus petite que l'image 206 à visualiser) et un changement de qualité : basse, moyenne et haute. Afin d'anticiper ces actions et donc d'améliorer l'interactivité entre l'utilisateur et l'animation, des requêtes de pré-chargement sont incluses dans le fichier SWF. Ces requêtes composent une classe de requêtes appelées par la suite Rpl. Elles permettent d'obtenir les données image permettant d'effectuer un zoom et un panoramique dans chaque direction pour une qualité 15 basse. On peut noter que si l'image incluse dans le fichier SWF a une qualité autre (moyenne ou haute), ces requêtes seront définies en fonction de ce choix. On parlera alors respectivement de classes de requêtes Rpm et Rph. Par la suite, la classe Rp sera aussi employée. Cette classe regroupe les requêtes des classes Rpl, Rpm et Rph. Comme on l'a déjà mentionné, l'utilisateur peut interagir avec l'animation en demandant un zoom sur une partie de l'image, un changement de qualité ou un panoramique selon une direction. Ces actions sont transcrites sous forme de requêtes qui composent une classe de requêtes appelées par la suite Ru. En résumé, trois classes de requêtes sont potentiellement présentes sur la machine client 2: Ra, Rp et Ru. Les requêtes de ces trois classes ont un caractère différent: - les requêtes de la classe Ra évoluent temporellement et sont prédictibles. Elles sont optionnelles car un fichier SWF qui ne contiendrait que 30 des images JPEG2000 n'aurait pas besoin de ce type de requêtes; - les requêtes de la classe Rp sont prédictibles, dans le sens o un jeu de requêtes est inclus dans le fichier SWF. On peut également noter que ces requêtes évoluent selon les actions de l'utilisateur. En effet, en revenant à notre exemple, si l'utilisateur modifie la qualité de l'image, le jeu de requêtes Rpl devient obsolète et un nouveau jeu Rpm (par exemple) doit être engendré de façon que les données image récupérées aient la même qualité que l'image 5 visualisée. Ce type de requêtes est optionnel car on peut créer un fichier SWF sans pour cela prévoir des requêtes de pré-chargement (c'est actuellement le cas des outils d'édition d'animations Flash); - les requêtes Ru sont imprédictibles. Ce type de requêtes est également optionnel car une animation peut ne pas autoriser d'interactions 10 avec un utilisateur. L'organigramme de la figure 3 illustre la phase d'initialisation du dispositif de la figure 1. Une fois que l'utilisateur a établi une connexion avec la machine serveur 1 de la figure 1, l'unité 25 d'envoi de requêtes de la machine client 2 est reliée à l'unité 10 de réception de requêtes de la machine serveur 1, 15 de façon que le serveur puisse recevoir des requêtes de la part du client. De même, l'unité 11 d'envoi de données de la machine serveur 1 est reliée à l'unité 27 de réception de données de la machine client 2, de façon que la machine serveur puisse envoyer des données numériques à la machine client. Dès que la machine client demande une animation, au travers de l'unité 25 d'envoi de 20 requêtes, la machine serveur réceptionne cette requête au travers de l'unité 10 de réception de requêtes et récupère le fichier SWF à envoyer à partir de l'unité 13 de stockage de données. Ce fichier est envoyé au travers de l'unité 11 d'envoi de données. La machine client 2 réceptionne ce fichier à partir de l'unité 27 de 25 réception de données et le stocke dans l'unité 21 de stockage de données (étape E300). De plus, au cours de cette étape, la machine client 2 initialise une liste L qui contiendra des éléments E, relatifs à chaque requête stockée dans l'unité 22 de stockage de requêtes, et ce quelle que soit la classe à laquelle la requête appartient. Chaque élément E de cette liste est mémorisé dans l'unité 30 22. Il contient une référence identifiant la requête, une variable C représentant sa classe, une variable P définissant sa priorité et une variable binaire W qui vaut 1 si la requête est valide et 0 sinon. L'étape E300 est suivie d'une étape E301 au cours de laquelle la machine client 2 extrait les données image JPEG2000 du fichier SWF et les stocke dans l'unité 21 de stockage de données. De plus, la qualité Q de l'image JPEG2000 récupérée est mémorisée dans l'unité 21. L'étape E301 est suivie d'un test E302 au cours duquel la machine client 2 teste si le fichier SWF contient des requêtes de la classe Rp, c'estàdire des requêtes de pré-chargement, que ces requêtes soient du type Rpl (associées à l'image basse qualité), Rpm (moyenne qualité) et/ou Rph (haute qualité). Selon un mode préféré de réalisation de l'invention, seules des 10 requêtes de la classe Rpl sont présentes. Si le test E302 est négatif, il est suivi d'un test E308 décrit ultérieurement. Si le test E302 est positif, la machine client 2 extrait ces requêtes du fichier SWF et les stocke dans l'unité 22 de stockage de requêtes (étape E303). De plus, pour chacune des requêtes extraites, la machine client 2 crée un 15 nouvel élément E de la liste L. L'étape E303 est suivie d'une étape E304 au cours de laquelle la machine client 2 récupère la qualité Q stockée dans l'unité 21 de stockage de données et initialise les variables W et C de chacun des éléments E créés à l'étape précédente, selon la règle suivante: 1) W = 1 si la requête permet de récupérer des données d'image de même qualité que l'image JPEG2000 mémorisée, 2) W =0 sinon, 3) C = Rpl si Q = basse, 4) C =Rpm si Q =moyenne, 5) C =Rph si Q =haute. L'étape E304 est suivie d'une étape E305 au cours de laquelle la machine client 2 calcule la priorité P de chacun des éléments E selon l'équation suivante: P = K1/N avec KI = PRIOMAX x Nmin = PRIOMIN x Nmax o les valeurs PRIOMIN et PRIOMAX sont fixées au préalable, et Nmin et Nmax déterminent la taille respectivement minimale et maximale des données image récupérées par une requête. La seule contrainte sur ces quatre valeurs 1 3 est que la relation PRIOMIN x Nmax = PRIOMAX x Nmin soit respectée de façon à obtenir une priorité P comprise dans l'intervalle [PRIOMIN,PRIOMAX] et ce quelle que soit la requête. L'étape E305 est suivie d'une étape E306 au cours de laquelle la 5 machine client 2 met à jour les requêtes Rp comme décrit plus loin à l'aide de la figure 4. L'étape E306 est suivie d'une étape E307 au cours de laquelle la machine client 2 inclut les éléments E correspondant aux requêtes Rp ainsi formés dans la liste L. L'étape E307 est suivie du test E308 au cours duquel la machine client 2 teste si le fichier SWF contient des requêtes de la classe Ra. Si le test E308 est négatif, il est suivi d'une étape E312 décrite ultérieurement. Si le test E308 est positif, la machine client 2 extrait ces requêtes du fichier SWF et les stocke dans l'unité 22 de stockage de requêtes (étape E309). 1 5 De plus, pour chacune de ces requêtes, la machine client 2 crée un nouvel élément E et initialise les variables W à I et C à Ra. L'étape E309 est suivie d'une étape E310 au cours de laquelle la machine client 2 calcule la priorité P de chacun des éléments E ainsi créés selon les équations suivantes P =PRIOMAX si temps courant = temps auquel les données doivent être jouées, P =max(PRIOMIN,PRIOMAX/(temps auquel les données doivent être jouées - temps courant)). Ainsi, l'évolution de la priorité suit l'évolution temporelle de 25 l'animation. Certaines données, jugées initialement comme n'étant pasnécessaires, le deviennent au cours du temps. Leur priorité augmente en conséquence. L'étape E310 est suivie d'une étape E311 au cours de laquelle la machine client 2 inclut les éléments des requêtes Ra ainsi formés dans la liste 30 L. L'étape E311 est suivie de l'étape E312 d'envoi de requêtes décrite plus loin à l'aide de la figure 5. L'organigramme de la figure 4 illustre la mise à jour d'un jeu de requêtes de la classe Rp. Comme on l'a expliqué en décrivant la figure 3, à chaque requête Rp est associé un élément E de la liste L. Lors d'une étape E400, la machine client 2 initialise un compteur I à la position du premier élément E du jeu de requêtes à traiter. Cette étape est suivie d'un test E401 au cours duquel la machine client 2 teste si la priorité de l'élément courant I est inférieure à PRIOMIN, c'està-dire si la quantité N des données image récupérées par cette requête est supérieure à Nmax. Si le test E401 est négatif, il est suivi d'un test E407 décrit 1 0 ultérieurement. Dans le cas contraire, le test E401 est suivi d'une étape E402 au cours de laquelle la requête est éclatée en autant de requêtes que nécessaire de façon que chacune d'entre elles récupère une quantité de données inférieure ou égale à Nmax et que la totalité des données récupérées par ces 15 nouvelles requêtes corresponde à la quantité de données qui aurait été récupérée par la requête initiale. A chacune de ces nouvelles requêtes est associé un élément E. L'étape E402 est suivie d'une étape E403 au cours de laquelle la machine client 2 initialise la variable W de chacun des nouveaux éléments 20 créés de façon similaire à l'étape E304 de la figure 3. Les étapes suivantes E404 et E405 sont identiques respectivement aux étapes E305 et E307 de la figure 3. L'étape E405 est suivie d'une étape E406 au cours de laquelle la machine client 2 supprime l'élément correspondant à la requête courante I et la 25 requête courante I de l'unité 22 de stockage de requêtes. Cette étape est suivie du test E407 au cours duquel la machine client 2 teste si la priorité de l'élément courant I est supérieure à PRIOMAX, c'est-àdire si la quantité N des données image récupérées par cette requête est inférieure à Nmin. Si le test E407 est négatif, il est suivi d'un test E413 décrit 30 ultérieurement. Dans le cas contraire, le test E407 est suivi d'une étape E408 au cours de laquelle la machine client 2 fusionne cette requête avec la requête ayant la plus faible priorité (i.e. la plus grande valeur de N) de façon que la somme des priorités de ces deux requêtes (respectivement la somme des quantités de données récupérées par les deux requêtes) soit supérieure (respectivement inférieure) à PRIOMIN (respectivement Nmax). L'étape E408 est suivie d'une étape E409 au cours de laquelle la machine client 2 initialise les variables W et C du nouvel élément créé, de façon similaire à l'étape E304 de la figure 3. Les étapes suivantes E410 et E411 sont identiques respectivement aux étapes E305 et E307 de la figure 3. L'étape E411 est suivie d'une étape E412 au cours de laquelle la machine client 2 supprime les éléments correspondant aux deux requêtes fusionnées et les deux requêtes de l'unité 22 de stockage de requêtes. L'étape E412 est suivie du test E413 au cours duquel la machine client 2 teste si l'élément courant est le dernier à traiter. Si le test E413 est 15 positif, le processus de mise à jour s'arrête. Sinon, le test E413 est suivi d'une étape E414 qui considère l'élément suivant (incrémentation d'une unité du compteur 1). L'étape E414 est suivie de l'étape E401 précédemment décrite. L'organigramme de la figure 5 illustre le fonctionnement du dispositif 20 de la figure 1 une fois la phase d'initialisation de la figure 3 terminée. Tout d'abord, lors d'un test 500, la machine client 2 teste si l'utilisateur a demandé une action particulière sur l'animation à partir de l'unité 24 de réception de requêtes. Selon un mode préféré de réalisation de l'invention, l'utilisateur a la possibilité de demander trois actions sur l'image 25 JPEG2000: zoom, panoramique et changement de qualité. Dès qu'une action est demandée, elle est stockée temporairement dans l'unité 22 de stockage de requêtes. Si le test 500 est négatif, il est suivi d'un test E509 lors duquel la machine client 2 teste si des requêtes de la classe Rp sont contenues dans la 30 liste L. Si c'est le cas, le test E509 est suivi d'une étape E510 de mise à jour des variables W et C similaire à l'étape E304 de la figure 3. L'étape E510 est suivie d'un test E511 décrit ci-dessous. Si le test E509 est négatif, il est suivi du test E51 1, au cours duquel la machine client 2 teste si des requêtes de la classe Ra sont contenues dans la liste L. Si ce n'est pas le cas, le test E511 est suivi d'une étape E513 décrite ultérieurement. Si c'est le cas, le test E51 1 est suivi d'une étape E512 au cours 5 de laquelle la machine client 2 met à jour les requêtes de la classe Ra selon la règle de l'étape E310 de la figure 3. L'étape E512 est suivie de l'étape E513 au cours de laquelle la machine client 2 trie les requêtes de la liste L. Selon un mode préféré de réalisation de l'invention, les requêtes sont classées selon leurs priorités et 10 indépendamment de leur classe, de la plus probable à la moins probable. L'étape E513 est suivie d'une étape E514 au cours de laquelle la machine client 2 envoie la requête la plus prioritaire parmi les requêtes contenues dans la liste L au travers de l'unité 25 d'envoi de requêtes. Une fois la requête envoyée, elle est supprimée, ainsi que l'élément associé de l'unité 24 15 de réception de requêtes et de la liste L. L'étape E514 est suivie du test E500 précédemment décrit. L'algorithme s'arrête à l'étape E514 à la demande de l'utilisateur selon un mode préféré de réalisation de l'invention. Si le test E500 est positif, c'est-à-dire si le client a demandé une 20 action particulière sur l'animation, le test E500 est suivi d'une étape E501 au cours de laquelle la machine client 2 envoie la requête Ru. L'étape E501 est suivie d'un test E502 au cours duquel la machine client 2 teste si la liste L contient des éléments de la classe Rp. Si ce n'est pas le cas, le test E502 est suivi de l'étape E513 précédemment décrite. Si la liste L contient des éléments de la classe Rp, le test E502 est suivi d'une étape E503 au cours de laquelle la machine client 2 supprime des requêtes Rp (et leurs éléments associés) de la liste L et de l'unité 22 de stockage de requêtes selon les données numériques stockées dans l'unité 21 de stockage de données. En effet, au fur et à mesure que des requêtes sont 30 envoyées, les données image reçues sont stockées dans cette unité. De ce fait, pour éviter de demander plusieurs fois les mêmes données, certaines requêtes de la classe Rp deviennent obsolètes. Elles sont supprimées à cette étape à la fois de l'unité 22 de stockage de requêtes et de la liste L. L'étape E503 est suivie d'une étape E504 au cours de laquelle la machine client 2 crée de nouvelles requêtes de la classe Rp (et de nouveaux 5 éléments E). En effet, selon les actions de l'utilisateur, certaines requêtes de pré-chargement sont nécessaires. Par exemple, si l'image JPEG2000 est visualisée à basse qualité et que l'utilisateur désire la visualiser à moyenne qualité, les requêtes de préchargement pour anticiper un zoom ou un panoramique doivent permettent de récupérer des données image à qualité 10 moyenne et non plus à basse qualité, de façon à visualiser l'image à une qualité constante. L'étape E504 est suivie d'une étape E505 au cours de laquelle la machine client 2 met à jour les variables W, c'est-à-dire valide ou non les requêtes, de façon similaire à l'étape E304 de la figure 3. L'étape E505 est suivie d'une étape E506 au cours de laquelle la machine client 2 met à jour les nouvelles requêtes créées (s'il y a lieu) de façon similaire à celle décrite par la figure 4. L'étape E506 est suivie d'une étape E507 au cours de laquelle la machine client 2 calcule les priorités de ces requêtes Rp de façon similaire à 20 l'étape E305 de la figure 3. L'étape E507 est suivie d'une étape E508 au cours de laquelle la machine client 2 inclut les nouvelles requêtes Rp dans la liste L. L'étape E508 est suivie de l'étape E513 précédemment décrite. Il est à noter que dans le cas o aucune nouvelle requête ne serait 25 créée à l'étape E504, l'étape E504 est suivie de l'étape E513. En référence à la figure 6, est décrit un exemple d'appareil de communication programmable mettant en oeuvre l'invention. Cet appareil comprend un dispositif de gestion des transmissions selon l'invention, tel que celui représenté sur la figure 1 et dont le 30 fonctionnement est décrit en référence aux figures 3 à 5. L'appareil est connecté, de façon identique au dispositif de la figure 1, à un appareil de communication jouant le rôle de machine serveur. Selon le mode de réalisation choisi et représenté sur la figure 6, un appareil mettant en oeuvre l'invention est par exemple un microordinateur 600 ou une station de travail. L'appareil 600 comporte un bus de communication 602 auquel sont reliés: une unité centrale de traitement 603 (microprocesseur), qui exerce la fonction de l'unité 28 de commande de la figure 1; - une mémoire morte 604, pouvant comporter les programmes "Prog1" et "Prog2"; - une mémoire vive 606, comportant des registres 607 adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités, notamment, la liste L des éléments et les listes des requêtes Rp, Ra, les éléments de cette liste L: W, C, P, 1, PRIOMAX, PRIOMIN, mentionnés en référence aux figures précédentes; - un écran 608 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 610 ou de tout autre moyen tel qu'un dispositif de pointage (non représenté), comme par exemple une souris ou un crayon optique; - un disque dur 612 pouvant comporter les programmes "Progl" et "Prog2" précités; - un lecteur de disquettes 614 adapté à recevoir une disquette 616 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention; - une interface de communication 618 reliée à un réseau de 25 communication 620, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données; - une caméra numérique 601, ou tout autre dispositif d'acquisition d'images. Dans le cas de données audio, l'appareil comprend en outre une 30 carte d'entrées/sorties reliée à un microphone (non représentés). Le bus de communication 602 permet la communication et l'interopérabilité entre les différents éléments inclus dans le micro-ordinateur 600 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du micro-ordinateur 600 directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 600. Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus de traitement des requêtes selon l'invention, peut être stocké par exemple sur le disque dur 612 ou en mémoire morte 604. Selon une variante, la disquette 616 peut contenir des données ainsi 10 que le code exécutable des programmes précités qui, une fois lu par l'appareil 600, sera stocké sur le disque dur 612. En seconde variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 620, via l'interface 618, pour être stocké comme décrit précédemment. Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes 20 dont l'exécution permet la mise en oeuvre du procédé selon l'invention. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage de l'appareil 600 avant d'être exécutés. L'unité centrale 603 va commander et diriger l'exécution des 25 instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées sur le disque dur 612 ou dans la mémoire morte 604 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 612 ou la mémoire ROM 604, 30 sont transférés dans la mémoire vive RAM 606 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Il convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques, par exemple figé dans un circuit intégré dédié (ASIC, en anglais "Application Specific lntegrated Circuit'). REVENDICATIONS 1. Procédé de gestion de requêtes d'au moins deux classes distinctes, portant sur des données multimédia, échangées par un appareil de 5 communication (2) et au moins une source de données (1) connectés par l'intermédiaire d'un réseau de communication (3), caractérisé en ce que ledit procédé comporte des étapes, effectuées au niveau de l'appareil de communication (2), de: - validation (E505, E510) d'au moins une requête d'au moins une 10 première classe de requêtes, la validation tenant compte des données multimédia reçues à partir d'au moins une deuxième classe de requêtes; et - affectation dynamique d'une priorité (E512, E507) à chacune des requêtes validées, suivant des caractéristiques desdites requêtes validées. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte 15 en outre une étape de décision (E513, E514) quant à la transmission d'au moins une requête validée, en fonction de la priorité affectée à ladite requête. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comporte en outre une étape de mise à jour (E503, E504, E506) des requêtes d'au moins une première classe, la mise à jour tenant compte des données 20 multimédia reçues à partir d'au moins une requête d'au moins une deuxième classe. 4. Procédé selon la revendication 1, 2 ou 3, caractérisé en ce que ledit appareil de communication (2) et ladite source de données (1) sont connectés par une connexion de type HTTP. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données sont des animations Flash et/ou des données d'images comprimées suivant la norme JPEG2000. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdites requêtes sont associées à l'animation d'un objet 30 (Ra) et/ou à la réalisation d'un zoom ou d'un panoramique ou d'un changement de qualité sur une image (Rp) et/ou à des interactions entre un utilisateur et une animation (Ru). 7. Dispositif de gestion de requêtes d'au moins deux classes distinctes, portant sur des données multimédia, échangées par un appareil de communication (2) et au moins une source de données (1) connectés par l'intermédiaire d'un réseau de communication (3), caractérisé en ce que ledit dispositif comporte: - des moyens de validation d'au moins une requête d'au moins une première classe de requêtes, la validation tenant compte des données multimédia reçues à partir d'au moins une deuxième classe de requêtes; et - des moyens d'affectation dynamique d'une priorité à chacune des 10 requêtes validées, suivant des caractéristiques desdites requêtes validées. 8. Dispositif selon la revendication précédente, caractérisé en ce qu'il comporte en outre des moyens de décision quant à la transmission d'au moins une requête validée, en fonction de la priorité affectée à ladite requête. 9. Dispositif selon la revendication 7 ou 8, caractérisé en ce qu'il 15 comporte en outre des moyens de mise à jour des requêtes d'au moins une première classe, la mise à jour tenant compte des données multimédia reçues à partir d'au moins une requête d'au moins une deuxième classe. 10. Dispositif selon la revendication 7, 8 ou 9, caractérisé en ce que ledit appareil de communication (2) et ladite source de données (1) sont 20 connectés par une connexion de type HTTP. 11. Dispositif selon l'une quelconque des revendications 7 à 10, caractérisé en ce que les données sont des animations Flash et/ou des données d'images comprimées suivant la norme JPEG2000. 12. Dispositif selon l'une quelconque des revendications 7 à 11, 25 caractérisé en ce que lesdites requêtes sont associées à l'animation d'un objet (Ra) et/ou à la réalisation d'un zoom ou d'un panoramique ou d'un changement de qualité sur une image (Rp) et/ou à des interactions entre un utilisateur et une animation (Ru). 13. Appareil de communication, caractérisé en ce qu'il comporte un 30 dispositif selon l'une quelconque des revendications 7 à 12.