FR 2831688 A1 20030502 FR 0114093 A 20011030 La présente invention concerne un procédé de traitement d'une requête d'obtention de donnces numériques multimédia. L'avancement technologique des appareils de communication numériques tels que les téléviseurs, les micro-ordinateurs de poche, les micro- ordinateurs classiques ou tout autre appareil miniaturisé est tel que, dans les années à venir, il sera très probablement possible d'échanger des données de type multimédia et, par exemple, audio eVou vidéo entre ces différents appareils. Des études de marché montrent, par ailleurs, que les utilisateurs sont prêts à acheter de tels appareils de communication à condition que le prix ne soit pas trop excessif et, surtout, que les services rendus soient de bonne qualité. Suite à l'identification de ce nouveau marché, de nombreuses études ont été menées concernant la miniaturisation des composants électroniques, de manière à obtenir des appareils ayant des capacités de mémoire et de calcul élevées. En outre, de nombreux organismes de normalisation ont mis en place des standards permettant d'unifier les échanges de données entre ces appareils aux caractéristiques différentes. Ces standards, tels que ceux de la famille IEEE 802, permettent à la fois la mise en _uvre et la gestion du transfert des données via un réseau particulier. Le standard IEEE 802.11 et son homologue européen HYPERLAN sont dédiés aux réseaux locaux sans fil. Ils sont particulièrement étudiés actuellement car ce sont des réseaux larges bandes permettant de transmettre des données audio eVou vidéo entre deux machines qui sont géographiquement proches. Ces standards sont donc particulièrement adaptés pour développer des réseaux locaux sans fil à l'intérieur des habitations. Les solutions techniques étudiées actuellement dans le cadre des standards susvisés appliqués aux réseaux locaux domestiques permettent de transmettre des données numériques soit entre une machine dite serveur et une machine dite client (transmission point à point), soit entre le serveur et un groupe de clients, soit encore entre le serveur et plusieurs clients (communication multi-points) et ce, sans aucun fil. Dans cet environnement, les données sont stockées sur le serveur qui centralise toutes les communications avec le ou les clients. Ce serveur peut également servir de passerelle avec le monde extérieur (Internet, télévision, caméscope...). Il convient de noter que les réseaux locaux domestiques peuvent être de nature hétérogène, c'est-à-dire qu'ils peuvent, par exemple, être pour partie constitués de liaisons sans fil et pour partie de liaisons filaires. Si de nombreux projets étudient la mise en _uvre de services autour de la télévision interactive et l'échange d'informations sur lèlnternet, peu d'entre eux traitent des problèmes liés à la mise en _uvre de réseaux locaux domestiques, à savoir la mise en place de solutions permettant d'obtenir une qualité de services acceptable. Le serveur étant relié au monde extérieur, les données stockées sont de tailles diverses. Le transport de ces donnces à travers un réseau local n'est donc pas un service aisé à mettre en place. Par ailleurs, lorsqu'un premier appareil de communication, jouant le rôle d'un serveur, doit traiter une requête d'obtention de données multimédia provenant d'un second appareil relié au premier appareil à travers un réseau de communication qui n'est pas nécessairement un réseau local, se pose le problème du temps de traitement de cette requête pour répondre au second appareil. Ce temps de traitement peut étre d'autant plus élevé que les données demandées dans une requete sont de plus en plus adaptées en fonction de différents paramètres ou descripteurs qui caractérisent cette requete. Parmi ces descripteurs on trouve: - les caractéristiques du réseau de transmission (bande passante, taux d'erreur, délai...), - les informations relatives au contenu demandé (audio, vidéo, format de compression utilisé...), -les préférences de l'utilisateur ayant émis la requete (type de présentation, résolution, cadence vidéo, nombre de couleurs, temps d'attente À). - certaines caractéristiques du second appareil de communication telles que la taille de l'écran de visualisation de l'appareil et la profondeur de couleurs que cet appareil peut supporter. Ainsi, selon la requete formulée par l'utilisateur le temps de traitement de celle-ci peut varier de manière considérable et être relativement long, voire, dans certains cas, occasionner un temps de réponse inacceptable pour l'utilisateur. On connat un système de communication d'après l'article "Adapting multimedia Internet content for Universal Access" de R. Mohan, J. Smith, C-S. Li, IEEE Transactions on Multimedia, Mars 1999, qui prévoit de constituer une base de donnces répertoriant les différentes catégories d'appareils de communication qui peuvent se connecter à un serveur. Pour chaque catégorie d'appareil, le système prend en compte la taille de l'écran de visualisation de cette catégorie d'appareil, la profondeur de couleurs que l'appareil peut supporter (nombre de bits par composante de couleur) et les garde en mémoire. Lorsque le système reconnat dans une requete provenant d'un des appareils et visant à obtenir des données vidéo, les caractéristiques susvisées de cet appareil, alors le système sait d'emblée quel(s) algorithme(s) de codage utiliser pour adapter le codage de données à ces caractéristiques. On conna^t également un autre système de communication d'après l'article intitulé "A framework for adaptive content delivery in heterogeneous network environments" de W.Y. Ma et al., paru dans Multimedia Computing and Networking 2000, Janvier 2000. Dans ce système, il est prévu d'adapter le contenu de pages Web consultées sur lèlnternet par un utilisateur en fonction des préférences de l'utilisateur pour la visualisation de ces pages. Les systèmes identifiés ci-dessus ne sont pas entièrement satisfaisants en ce qui concerne le temps de traitement d'une requête émise par un utilisateur et visant à obtenir des données numériques multimédia. Il serait en effet intéressant d'améliorer ce temps de traitement afin de raccourcir ie temps nécessaire pour fournir la réponse attendue par l'utilisateur. La présente invention a ainsi pour objet un procédé de traitement d'une requête d'obtention de donnces numériques multimédia, ladite requête comportant plusieurs descripteurs caractérisant celle-ci, caractérisé en ce que ledit procédé comporte les étapes suivantes: analyse des descripteurs caractérisant la requête en cours de traitement, - comparaison du résultat de l'analyse avec les descripteurs d'autres requêtes traitées antérieurement, - en fonction du résultat de la comparaison, décision quant à savoir si la requête en cours de traitement est: identique à une requête traitée antérieurement, en ce sens que les deux requêtes comportent les mêmes descripteurs de requête, similaire à une requête traitée antérieurement, en ce sens que les deux requêtes ont en commun au moins un descripteur de requête, nouvel le par rap port aux requêtes traitées antérieu re ment. Corrélativement, I'invention a également pour objet un dispositif de traitement d'une requête d'obtention de donnces numériques multimédia, ladite requête comportant plusieurs descripteurs caractérisant celle-ci, caractérisé en ce que ledit dispositif comporte: des moyens d'analyse des descripteurs caractérisant la requête en cours de traitement, -des moyens de comparaison du résultat de l'analyse avec les descripteurs d'autres requêtes traitées antérieurement, - des moyens de décision, en fonction du résultat de la comparaison, quant à savoir si la requête en cours de traitement est: identique à une requête traitée antérieurement, en ce sens que les deux requêtes comportent les mêmes descripteurs de requête, similaire à une requête traitée antérieurement, en ce sens que les deux requêtes ont en commun au moins un descripteur de requête, nouvelle par rapport aux requêtes traitées antérieurement. En déterminant si la requête en cours de traitement est identique, similaire ou nouvelle par rapport aux requêtes traitées antérieurement, I'invention permet de prendre rapidement une décision sur le traitement à effectuer pour répondre à la requête émise par un utilisateur. Par exemple, si la requête courante est identique à une requête antérieure déjà traitée, le traitement de cette requête sera accéléré puisque le ou les paramètres de codage nécessaires à l'adaptation des données à la requête de l'utilisateur auront déjà été déterminés antérieurement et seront donc déjà disponibles. De même, si la requête courante est similaire à une requête antérieure déjà traitée, une quantité de travail non négligeable aura déjà été effectuée antérieurement et les résultats de ce travail qui seront déjà disponibles permettront d'accélérer le traitement de la requête courante. On notera que lorsque la requête courante et une requête traitée antérieu rement ont en commu n certains descri pteu rs de requêtes ma is pas tou s ceux de la requête courante, alors cette dernière est également considérce comme similaire à la requête antérieure. Ainsi, lorsqu'une telle requête courante a été identifice à l'étape de décision susvisée, cela permet de réduire davantage encore le temps de traitement de cette requête par rapport au cas o un seul descripteur de requête est commun entre la requête courante et la requête antérieure. En effet, la tâche restant à accomplir pour adapter les données demandées au(x) descripteur(s) de requête non commun(s) à la requête antérieure sera moins importante puisque les descripteurs de requête en commun sont cette fois ci plus nombreux et donc le travail d'adaptation effectué antérieurement et déjà disponible sera plus important. En effet, les opérations accomplies antérieurement pour adapter des donnces à plusieurs descripteurs de requête, comme par exemple le contenu des données et des caractéristiques de la machine client dont dispose l'utilisateur, occasionnent un travail plus important que pour un seul descripteur de requête et le résultat de ces opérations est disponible pour le traitement de la requête courante. Selon un premier cas, lorsque la requête en cours de traitement est considérée comme similaire à une requête antérieure, le procédé comporte une étape de prise en compte d'au moins un paramètre de codage qui va être utilisé pour le codage des données et qui a déjà été déterminé antérieurement en fonction dudit au moins un descripteur de requête en commun avec la requête antérieure. Ainsi, on peut se servir du ou des paramètres de codage précités sans avoir besoin de les recalouler. Selon une caractéristique, lorsque la requête en cours de traitement est considérée comme similaire à une requête antérieure traitée, le procédé comporte une étape de détermination d'au moins un paramètre dit de codage qui va être utilisé pour le codage des données, ledit au moins un paramètre de codage étant déterminé en fonction d'au moins un descripteur caractérisant la requête en cours de traitement et qui n'est pas en commun avec la requête antérieure. De cette façon, les opérations de détermination de ce ou ces paramètres de codage occasionnent moins de traitement que dans le cas o l'on doit également tenir compte, pour le calcul, du ou des descripteurs de requete en commun. Selon un deuxième cas, lorsque la requête en cours de traitement est considérée comme identique à une requête antérieure, le procédé comporte une étape de prise en compte d'au moins un paramètre de codage qui va être utilisé pour le codage des données et qui a déjà été déterminé antérieurement en fonction d'au moins certains des descripteurs caractérisant la requête en cours de traitement. Ceci permet de réutiliser les résultats des opérations de détermination du ou des paramètres de codage effectuées antérieurement pour la requête antérieure déjà traitée. Selon une caractéristique, le procédé comporte une étape de détermination quant à savoir si la requête courante a une fréquence d'apparition qui est supérieure à un seuil prédéterminé. En surveillant ce critère il est possible d'identifier les requêtes qui sont les plus fréquentes. A cet effet, on notera qu'il est également possible de surveiller les requêtes les moins fréquentes, voire de supprimer certaines de ces requêtes qui n'apparaissent que peu ou pas du tout pendant une période de référence. Là également, on peut surveiller si la fréquence d'apparition est inférieure à un seuil prédéterminé et ce, pendant une période de référence. La suppression des requêtes les moins fréquentes permet d'alléger la capacité mémoire o les requêtes antérieures sont stockées. Selon une autre caractéristique, lorsque la fréquence d'apparition de la requête courante est supérieure au seuil prédéterminé, le procédé comporte une étape ultérieure de stockage des données codées avec ledit au moins un paramètre de codage déterminé antérieurement. Ainsi, pour les requêtes les plus fréquentes le temps de traitement est encore davantage réduit puisque le contenu adapté des données codées est stocké et donc très rapidement disponible en cas d'identification de requête identique. Selon un troisième cas, lorsque la requête en cours de traitement est considérée comme nouvelle, le procédé comporte une étape de détermination d'au moins un paramètre de codage qui va être utilisé pour le codage des données, ledit au moins un paramètre de codage étant déterminé en fonction d'au moins un descripteur caractérisant la requête courante. Dès lors que la requête courante n'est ni identique ni similaire à une requête antérieure déjà traitée elle est considérée comme nouvelle; Le fait d'avoir prévu deux autres cas avant de considérer qu'une requête est nouvelle permet de gagner du temps de traitement puisque tout le travail d'adaptation du ou des paramètres de codage aux descripteurs de la requête est effectué de façon moins systématique que si l'on ne considérait que deux cas: requête nouvelle ou identique. Selon une caractéristique, les étapes d'analyse, de comparaison et de décision sont effectuces dans un premier appareil de communication relié à un second appareil de communication par un réseau de communication. Un descripteur de la requête courante comporte par exemple: - au moins certaines des caractéristiques du second appareil de communication, à savoir, par exemple, la capacité de calcul de cet appareil, sa capacité mémoire..., ou - au moins certaines des caractéristiques du réseau de communication. Un descripteur de la requête courante peut également identifier les données multimédia à fournir au second appareil de communication. Un descripteur de la requête courante peut en outre spécifier les préférences de l'utilisateur ayant émis la requête en termes de présentation ou de mise en forme des données. Selon une caractéristique, la requête est considérce comme similaire à une requête antérieure lorsque sont pris en compte comme descripteurs de requête communs les données multimédia demandées dans la requête en cours de traitement et au moins un autre descripteur de requête. Ainsi, en prenant en compte comme descripteurs de requête le contenu des données et au moins un autre descripteur tel que, par exemple, des caractéristiques du second appareil de communication, on gagne plus de temps dans ie traitement que dans le cas o l'on ne prend en compte, par exemple, que des caractéristiques du second appareil. L'invention concerne également un appareil de communication comportant un dispositif tel que brièvement exposé ci-dessus. Selon un autre aspect, I'invention vise aussi: - un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'invention tel que celui exposé brièvement cidessus, et - un moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé selon l'invention tel que celui brièvement exposé ci-dessus. Selon encore un autre aspect, I'invention vise un programme d'ordinateur chargeable dans un appareil programmable, comportant des séquences d'instructions ou portions de code logiciel pour mettre en _uvre des étapes du procédé selon l'invention tel que brièvement exposé ci-dessus, lorsque ledit programme d'ordinateur est chargé et exécuté sur l'appareil 1 5 programmable. Les caractéristiques et avantages relatifs au dispositif, à l'appareil de communication comportant un tel dispositif, aux moyens de stockage d'informations et au programme d'ordinateur étant les mêmes que ceux exposés ci-dessus concernant le procédé selon l'invention, ils ne seront pas rappelés ici. D'autres caractéristiques et avantages de la présente invention appara^'tront plus clairement à la lecture de la description qui va suivre, faite en référence aux dessins annexés, sur lesquels: - la figure 1 représente de manière schématique une architecture de communication de type clientserveur dans laquelle l'invention peut être mise en _uvre; - la figure 2 représente un algorithme de traitement de données vidéo selon l'invention; -les figures 3a et 3b illustrent respectivement l'architecture et I'unité de stockage 170 du moteurde décision 17 de la figure 1; - la figure 3c illustre un algorithme de traitement d'une requête; - la figure 3d illustre un algorithme détaillant le processus de prise de décision lors du traitement d'une requête selon l'algorithme de la figure 3c; - la figure 4a illustre un aigorithme détaillant le fonctionnement de la mémoire 170 lors du traitement d'une requête identique à une requête antérieure; - la figure 4b illustre un algorithme détaillant le fonctionnement de la mémoire 170 lors du traitement d'une requête similaire à une requête antérieure; - la figure 4c illustre un algorithme détaillant le fonctionnement de la mémoire 170 lors du traitement d'une requête et, plus particulièrement, le processus d'effacement de requête; la figure 5 est un algorithme de transcodage des données, - la figure 6 est un mode de réalisation d'un appareil programmable mettant en _uvre l'invention. Sur la figure 1 est représentée une architecture de communication du type client-serveur dans laquelle l'invention est avantageusement mise en _uvre; Sur cette figure, un premier appareil de communication 1 jouant le rôle du serveur est relié à un deuxième appareil de communication 2 qui est la machine client, par l'intermédiaire d'un réseau de communication 3 et d'une connexion qui est considérée comme étant établie. Ce réseau est par exemple un réseau de communication local sans fil à l'intérieur d'une habitation. Plus particulièrement, ce réseau est conforme au standard IEEE802.1 1. Il s'agit dans l'exemple considéré d'une transmission point à point de données entre le serveur 1 et la machine client 2. Cependant, le principe reste applicable au cas o le serveur est connecté simultanément à plusieurs machines client qui peuvent requérir du serveur des données numériques multimédia et, par exemple, le même contenu d'une vidéo. Il convient toutefois, dans ce cas, de prendre en compte, d'une part, la gestion des processus d'adaptation et de transmission en parallèle des différentes versions adaptées des données demandées et, d'autre part, les accès multiples à la ou aux mémoires du serveur. On notera que les données stockées dans le serveur peuvent avoir été reçues de l'environnement extérieur à l'habitation, par exemple, par un autre réseau de communication tel que lèlnternet. Les données regroupées sous le terme données multimédia peuvent être, de manière non limitative, des images fixes, des vidéos, du son, des données de type texte (ex: documents graphiques...), des documents en langage HTML, des signaux issus d'un télécopieur ou d'une imprimante... Dans l'exemple de réalisation considéré, on considérera de préférence des données vidéo qui seront transmises sous forme compressée, sans perte, sur le réseau 3. Le dispositif selon l'invention permet de traiter une requête transmise par la machine client 2 et visant à obtenir des données multimédia et, plus particulièrement, de prendre une décision sur l'adaptation des données à transmettre en fonction de la requête. Le serveur 1 comporte le dispositif 4 selon l'invention qui peut comporter des éléments électroniques eVou des éléments logIciels. Le serveur 1 comprend une unité 5 de stockage de donnces numériques telles que des vidéos. Toutefois, le dispositif 4 selon l'invention pourrait, par exemple, être confondu avec le serveur 1. Les contenus de données disponibles sont stockés dans des formes compressées dans l'unité 5. Les formats de compression utilisés seront par exemple le format MP3 pour les données audio, le format JPEG pour les images et le format MPEG pour les vidéos. On notera que les vidéos sont créées, par exemple, par un caméscope numérique ou tout autre moyen d'acquisition de données ou bien sont transmises par un réseau de communication extérieur et sont stockées dans l'unité qui peut être incluse ou non dans le dispositif 4. Cette unité peut être, par exemple, une base de donnces locale ou distribuée. Le dispositif 4 comprend également une unité de stockage 6 destinée à mémoriser de façon temporaire des données numériques et des vidéos codées, ces données étant récupérées à partir de l'unité 5 de stockage. Les données récupérces par l'unité 6 sont, soit les valeurs associées à chacun des pixels de chaque image d'une vidéo, soit les informations propres à cette vidéo, à savoir la taille du fichier vidéo, le chemin permettant d'accéder à cette vidéo et, dans le cas o la vidéo est stockée sous forme compressée, ies paramètres de codage qui ont été utilisés pour coder cette vidéo. Le dispositif 4 selon l'invention comporte également une unité de commande 11 des différentes opérations exécutées dans ce dispositif. Le dispositif selon l'invention comprend des moyens d'analyse des requêtes soumises par différents utilisateurs et qui se présentent sous la forme des unités 13,14, 15 et 16. Chaque requête formulée par un utilisateur à partir d'une machine client du type de la machine 2 de la figure 1 comporte plusieurs descripteurs de requête qui caractérisent cette demière. Parmi ces descripteurs on trouve: - des caractéristiques de la machine client, - des caractéristiques du réseau, - des informations d'identification des données à fournir à la machine client, - les préférences spécifiées par l'utilisateur concernant la présentation ou la mise en forme des données à fournir. Les unités 13 à 16 évoquées plus haut analysent les descripteurs de requête indiqués ci-dessus. Le dispositif 4 comprend plus particulièrement une unité 13 de récupération des caractéristiques de la machine client 2, à savoir: - la capacité de calcul de cette machine et, plus particulièrement, la fréquence du processeur central qui correspond au temps mis pour exécuter une instruction, - la capacité mémoire disponible dans cette machine et, plus particulièrement, la taille de la mémoire vive (RAM) utilisable pour traiter les contenus demandés, c'est-à-dire pour effectuer leur décompression grâce à l'unité de codage, - la taille de l'unité de visualisation exprimoe en pixels. Le dispositif 4 comprend, en outre, une unité 14 de récupération des caractéristiques du réseau 3, à savoir principalement la bande passante disponible dans le réscau. Le dispositif 4 comprend une unité 15 qui récupère les informations sur le contenu demandé par l'utilisateur. Par exemple, pour une vidéo encodée au fommat MPEG-4 décrit par le standard "Inforrnation technology- Genenc coding of audio-visual objects - paff2: Visual', ISO/IEC JTC 1/SC 29N4G11 N3056, Décembre 1999, ce standard définit différents niveaux et profils qui permettent de déterminer des valeurs typiques des paramètres de description du contenu tels que: - la résolution spatiale des images composant la vidéo, - le nombre d'images par seconde, - le débit auquel est encodée la vidéo. Le dispositif 4 comprend également une unité 16 qui récupère les préférences que l'utilisateur a pu spécifier au moyen d'une interface graphique. Pour caractériser ces préférences, on considérera, par exemple, les paramètres suivants: - fréquence d'afffichage des images en nombre d'images par seconde, -résolution spatiale de ces images en nombre de lignes et de colonnes. Comme représenté sur la figure 1, le dispositif 4 selon l'invention comporte une unité de décision 17, appelée moteur de décision. Le moteur de décision a pour fonction de trouver le ou les paramètres de codage qui vont servir à coder les donnces destinces à la machine client 2 à l'origine de la requête et qui correspondent le plus possible aux préférences de l'utiiisateur, aux caractéristiques de la machine client et à l'état du réseau. Le moteur de décision doit trouver le ou les paramètres de codage les plus adaptés à partir des descripteurs de la requete considérée qui sont le contenu demandé par l'utilisateur, ses préférences, les caractéristiques du réseau 3 et les caractéristiques de la machine client 2. Dans l'exemple décrit, il existe plusieurs paramètres de codage qui forment ce que l'on appelle une "structure de décision" et qui sont de manière non limitative: - la résolution spatiale des images, - la fréquence d'afffichage de ces images, et - le débit alloué à la représentation du contenu compressé (en kilobits par seconde). Le processus de prise de décision sur l'adaptation du contenu et qui est effectué par le moteur de décision 17 sera décrit ultérieurement en référence aux figures 3a à 3d, et 4a à 4c. Le moteur de décision 17 pilote une unité ou module de transcodage 18 qui procède à l'adaptation des données demandées par l'utilisateur à partir des paramètres de codage de la structure de décision mentionnée ci-dessus. Par exemple, les opérations d'adaptation sont réalisées par l'intemmédiaire d'un ré-encodage au format MPEG4 décrit ci-dessus. Le processus d'adaptation effectué par le moduie de transcodage 18 sera décrit ultérieurement en référence à la figure 5. Le dispositif 4 comprend par ailleurs une unité 19 de transmission / réception de do nnées nu mé riqu es. L'unité 19 permet d'effectuer la transmission de données à la machine client 2, à travers le réseau 3, en réponse aux requêtes transmises àpartir de cette machine, ainsi que la réception de donnces provenant de la machine client. On notera que les différentes unités qui composent le dispositif selon l'invention et, plus généralement le serveur, résident sur la même machine. Cependant, il pourra être envisagé de distribuer ces unités sur plusieurs machines serveur et d'établir des communications entre ces différentes unités à travers le réseau de communication 3. Cette distribution des unités ne modifiant en rien la mise en _uvre de l'invention, on considérera par la suite, pour des raisons de simplicité, que toutes les unités sont localisées sur la même machine que nous appelons serveur. La machine client 2 comporte une unité de transmission/réception de données numériques 20. Cette unité 20 permet d'effectuer la transmission de donnces au dispositif 4 et notamment de requêtes visant à obtenir des données à travers le réseau 3, ainsi que la réception de données provenant du dispositif en réponse à de telles requêtes. La machine client 2 comporte également une unité 21 de stockage de données numériques, une interface graphique 22, une unité 23 de décodage identique à l'unité de codage non représentée du dispositif 4 et une unité de visualisation 24, pemmettant de visualiser les données décodées. L'interface graphique 22 permet à l'utilisateur de la machine client 2 d'interagir avec cette machine et de contrôler les différentes unités. La figure 2 illustre un algorithme comportant différentes instructions ou portions de code logiciel correspondant à des étapes du procèdé selon l'invention. Cet algorithme détaille le fonctionnement global du dispositif 4 de ia figure 1 Le programme informatique noté "Progr" qui est basé sur cet algorithme est mémorisé dans l'unité de stockage temporaire de données 6 de la figure 1 et exécuté par les différentes unités 13 à 19 sous le contrôle de l'unité de commande 11, ce qui pemmet ainsi de mettre en _uvre le procèdé selon l'invention. Ce programme est également stocké dans l'appareil de la figure 7. L'algorithme de la figure 2 comporte une première étape notée E200 au cours de laquelle le dispositif 4 de la figure 1 et, plus particulièrement, I'unité de réception 19 rec,oit une requête émise par l'unité de transmission 20 de la machine client 2. Par exemple, cette requête se présente sous la fomme d'une chane de caractères permettant d'identifier de fac,on unique des données vidéo mémorisées dans l'unité de stockage 5 du serveur 1, ainsi que les caractéristiques de la machine client dont provient la requête et les préférences formulées par l'utilisateur de la machine client, par exemple, quant à la visualisation de ces données vidéo. Les différents descripteurs de la requête sont illustrés à la figure 3b. Toutefois, il existe des cas o les caractéristiques du réseau ne sont pas présentes dans la requête mais peuvent être récupérées par l'unité 14 de la figure 1. Au cours de l'étape suivante E201, la requête provenant de la machine client 2 est transférée à l'unité de stockage temporaire 6 aux fins de mémorisation. L'étape E201 est suivie d'une étape E202 au cours de laquelle l'unité procède à une récupération des caractéristiques des données vidéo mémorisées dans l'unité de stockage 5 de la figure 1 (paramètres de codage initiaux, descriptif texte...), à partir du descripteur d'informations sur le contenu fourni par la requête. Le descripteur de contenu est représenté par le module 501 sur la figure 3b et les informations décrivant le contenu demandé sont, par exemple, la résolution spatiale de la vidéo, le nombre d'images par seconde de cette vidéo (résolution temporelle) et le débit de la séquence d'images. Les données vidéo récupérées dans l'unité de stockage 5 sont alors mémorisées dans l'unité de stockage temporaire 6. Au cours de l'étape suivante E203, I'unité 13 procède à l'obtention des caractéristiques de la machine client 2 qui a émis la requete mentionnce à l'étape E200, à partir du descripteur correspondant présent dans cette requête. Ces caractéristiques sont principalement la capacité de calcul de la machine client 2, la capacité mémoire dont elle dispose et la taille de son unité de visualisation 24 (écran). Ces caractéristiques sont stockées de façon temporaire dans l'unité de stockage 6 du dispositif 4 de la figure 1. L'étape E203 est suivie d'une étape E204 au cours de laquelie l'unité 14 obtient les caractéristiques du réseau de communication 3 (la bande passante disponible pour transmettre les donnces vidéo du dispositif 4 à la machine client 2) à partir du descripteur correspondant présent dans la requête. Lorsque ces caractéristiques ne sont pas présentes dans la requête, I'unité 14 peut envoyer un message de test à la machine client 2 que celle-ci lui retoume. L'unité 14 peut ainsi estimer le temps de transmission et donc la bande passante du réscau 3. Ces caractéristiques sont mémorisées dans l'unité de stockage temporaire 6. Au cours de l'étape suivante E205,1'unité 16 obtient les préférences de l'utilisateur que ce dernier a spécifiées dans la requête et les mémorise dans l'unité de stockage temporaire 6. On notera que chacune des unités 13 à 16 précitées procède à une analyse des descripteurs de la requête en cours de traitement pour en extraire les informations pertinentes qui vont être utiles dans la suite du traitement selon I'invention. Au cours de l'étape suivante E206, le moteur de décision 17 va prendre une décision quant à l'adaptation du contenu demandé par l'utilisateur aux caractéristiques de la machine client 2 et du réseau, ainsi qu'aux préférences de l'utilisateur. Lors de cette étape, on va déterminer le ou les paramètres de codage adaptés à la requête et qui vont être utilisés pour le codage des donnces à transmettre à la machine client 2. Le détail des opérations effectuées lors de cette étape sera fourni ultérieurement lors de la description faite en référence aux figures 3a à 3d et 4a à 4c. Cette étape est effectuée par l'unité 17 du dispositif 4 de la figure 1, sous contrôle de l'unité de commande 11, et à partir des informations disponibles dans l'unité de stockage temporaire 6. Au cours de l'étape suivante E207, le module 18 de la figure 1 effectue le transcodage des donnces à transmettre à la machine client 2 comme il sera décrit ultérieurement en référence à la figure 5. Lors de cette étape, le module de transcodage 18 adapte ies données à transmettre avec le ou les paramètres de codage détemminés à l'étape E206. Toutefois, dans certains cas qui seront également évoqués ci-après, le moteur de décision 17 décide que les donnces à transmettre à la machine client sont déjà disponibles sous forme transcodée dans l'unité de stockage 5 de la figure 1. L'étape E206 est alors directement suivie de l'étape E208. Au cours de l'étape E208, le dispositif 4 de la figure 1 et, plus particulièrement, I'unité de transmission 19 de celui-ci procède à la transmission des donnces vidéo qui ont été préalablement transcodées ou non à l'étape E207 vers la machine client 2. On notera que la transmission des donnces vidéo compressées se fait préférentiellement "à la volée?? (connu en terminologie anglosaxonne sous le terme "streaming"), c'est-à-dire que les informations nécessaires à l'utilisateur pour reconstruire une image sont mémorisées dans l'unité de stockage 6, puis sont transmises à la machine client 2 avant que toutes les données vidéo ne soient compressées. Ainsi, I'utilisateur reçoit au niveau de la machine client 2 les informations par paquets, dans chacun desquels se trouvent des informations permettant à cet utilisateur de décoder une image courante. Sur la figure 3a, apparaissent les différents modules constitutifs du moteur de décision 17. Le moteur de décision 17 comprend un module de mémoire 170 o l'on décide de stocker ies requêtes soumises au dispositif 4 de la figure 1 et la décision de transcodage qui y est associée une fois que les requêtes ont été traitées, ainsi que les paramètres d'adaptation d'un contenu particulier à un client particulier (module 507 de la figure 3b). Le contenu de la mémoire 170 ainsi que sa gestion sont décrits ci dessous en référence à la figure 3b. La figure 3b représente les différentes donnces stockées dans la mémoire 170 du moteur de décision 17. Ainsi, cette mémoire présente un module 500 qui définit le contexte d'une requête et qui est composé des descripteurs du contenu demandé 501, de la machine client 502 ayant émis la requête, des préférences de l'utilisateur 503 à * I'origine de la requête et du réseau 504. A ce contexte, sont associées les données supplémentaires suivantes: - un compteur 505 qui permet de conna^tre pour chaque contexte, le nombre de fois o il est apparu et de classer la liste des requêtes selon leur fréquence d'apparition; - la date de la demière apparition d'une requête 506 (date d'entrée en mémoire) qui permet, durant les moments d'inactivité du dispositif 4, d'effacer de la mémoire les requêtes les plus anciennes; - des descripteurs des paramètres d'adaptation du contenu au client 507 qui pemmettent une prise de décision accélérée lorsqu'une requête similaire à une requête présente en mémoire est soumise au dispositif 4; des descripteurs de la décision de transcodage 508 qui correspondent, par exemple, aux paramètres de contrôle d'un encodeur de vidéos au fommat MPEG-4, ces paramètres étant essentiellement un débit, une résolution spatiale et une résolution temporelle pour les images. La mémoire 170 du moteur de décision 17 est bornée et limitée à N contextes et à N décisions, de telle sorte que la consommation de mémoire par le procédé selon l'invention soit contrôlable et prédictible. De retour à la figure 3a, le moteur de décision comprend des modules 171 (module de lecture / écriture en mémoire), 172 (gestionnaire de la mémoire) et 173 (compteur des requêtes) qui permettent respectivement de récupérer, d'insérer des requêtes et de les classer en fonction de leur fréquence d'apparition. Le moteur de décision 17 comprend également un module 174 qui permet de comparer une requête en cours de traitement aux requêtes présentes en mémoire et qui ont donc été traitées antérieurement par le procédé selon l'invention. Trois résultats sont attendus en sortie de ce module: -la requête en cours de traitement a été identifiée parmi les requêtes antérieures; - une requête similaire a été identifice parmi les requêtes antérieures; - la requête en cours de traitement correspond à une nouvelle requête. Le premier résultat correspond au cas o le contexte de la requête en cours de traitement est le même que celui d'une requête déjà présente en mémoire (mêmes descripteurs de requête). Ce cas se rencontre, par exemple, lorsqu'un même utilisateur demande le même contenu, à partir de la même machine client et que l'état du réseau est identique à celui qu'il était lors du traitement de la requête antérieure. On considère que l'état du réseau est identique lorsque la bande passante disponible à l'instant t+1 diffère de celle disponible à l'instant t de plusieurs kilobits par seconde. Le second résultat correspond au cas o le contexte de la requête en cours de traitement possède des similarités avec une des requêtes présentes en mémoire (au moins un descripteur de requête en commun). Ce cas se rencontre, par exemple, lorsque l'état du réseau ou les préférences de l'utilisateur ont changé entre deux requêtes et que les caractéristiques du contenu (module 501 de la figure 3b) et du client (module 502 de la figure 3b) sont identiques. Dans ce cas, la prise de décision qui est effectuée par un module d'optimisation 175 (figure 3a) est simplifice puisque les paramètres d'adaptation au client 507 ont déjà été calculés antérieurement et sont déjà disponibles. Cette prise de décision simplifiée est illustrée SUF la figure 3d qui sera décrite ultérieurement. Le troisième résultat impose au moteur de décision 17 de prendre une décision en considérant tous les descripteurs du contexte (module 500 de la figure 3b) de la requête. Comme pour le cas précédent, cette prise de décision est également illustrée sur la figure 3d. Le moteur de décision 17 comprend en outre une unité 176 qui permet au moteur de décision 12 de communiquer avec les autres unités du dispositif 4 et, notamment, son unité de stockage temporaire 6. Les figures 3c, 3d et 4a à 4c illustrent les algorithmes de fonctionnement du moteur de décision des figures 3a et 3b. L'algorithme de chacune des figures 3c, 3d, 4a à 4c concerne des opérations particulières du traitement d'une requête selon l'invention et qui sont effectuées lors de l'exécution de l'étape E206 de la figure 2. Plus particulièrement, chaque algorithme comporte différentes instructions ou portions de code logiciel correspondant à des étapes du procédé de traitement d'une requête selon l'invention. Le programme informatique qui est basé sur cet algorithme est mémorisé dans l'unité de stockage temporaire de données 6 de la figure 1 et exécuté par le moteur de décision 17 sous le contrôle de l'unité de commande 11. Ce programme fait partie du programme "Progr" précité en référence à la figure 2 et est également stocké dans l'appareil de la figure 6. L'exécution du programme informatique basé sur cet algoritUme va mettre en _uvre le procédé permettant de prendre une décision sur l'adaptation du contenu à transmettre à la machine client consécutivement à sa requête. L'algorithme de la figure 3c illustre le procédé de traitement d'une requête courante et débute par une première étape E301 au cours de laquelle I'unité de lecture / écriture 176 du moteur de décision 17 ffigure 3a) récupère la requête préalablement mémorisoe dans l'unité de stockage temporaire 6 de la figure 1. Au cours de l'étape suivante E302, le moteur de décision 17 cherche dans sa mémoire 170 (figures 3a et 3b) si la requête en cours de traitement y est déjà totalement ou partiellement présente. Plus précisément, le module 174 effectue une comparaison de la requête courante avec les requêtes antérieures déjà traitées et stockées en mémoire dans le module 170. Cette opération consiste à examiner, pour la requête courante et pour chaque requête antérieure, les différents descripteurs de requête (paramètres décrivant le contexte de la requête et mémorisés dans le module 500 de la figure 3 b), en les comparant un par un. En fonction du résultat de cette comparaison, on peut décider si la requête courante est identique à une requête antérieure (étapes E303 à E305), similaire à une requête antérieure (étapes E306 à E308) ou nouvelle par rapport aux requêtes antérieures (étapes E309 à E311). Dans le cas o la requête courante est identifice comme étant identique à une requête déjà traitée, l'étape E302 est suivie de l'étape E303 qui consiste à incrémenter d'une unité le nombre d'occurrence de cette requête. Cette opération est illustrée sur la figure 4a qui est décrite ci-après. Au cours de l'étape suivante E304, la liste des requêtes présentes dans la mémoire est retrice par ordre de fréquence d'apparition décroissante. Ce tri est réalisé par le gestionnaire de la mémoire 172 de la figure 3a. On notera que dans le cas d'une requête identique, le procédé selon l'invention prévoit de prendre en compte le ou les paramètres de codage qui ont été déterminés antérieurement en fonction des descripteurs de la requête courante ou seulement de certains d'entre eux considérés comme prioritaires. Il n'est donc pas nocessaire de calculer de nouveau ces paramètres de codage, ce qui accélère le traitement de la requête. Au cours de l'étape suivante E305, la décision de transcodage est sauvegardée dans l'unité 6 du dispositif 4 o le transcodeur 18 la récupèrera pour effectuer le transcodage lors de l'étape E207 (figure 2). La figure 4a illustrant le fonctionnement de la mémoire 170 détaille les étapes E303 et E304 de la figure 3c et débute par une étape E400 au cours de laquelle on détermine l'instant o la requête courante est identifiée comme une requête présente en mémoire (requête n) par le comparateur de requêtes 174 (figure 3a). L'étape suivante E401 consiste à incrémenter d'une unité le compteur 505 (figure 3b) associé à cette requête n et qui comptabilise le nombre d'apparitions de chaque requête. A l'étape suivante E402, la date d'entrce en mémoire 506 associée à la requête n est rendue égale à la date courante. Au cours de l'étape E403, on teste si la valeur inscrite dans le compteur 505 de la requête n, Cn, est devenue supérieure à celle de la requête n-1, Cn-' Dans la négative, l'insertion de la requête est alors terminée. Dans l'affirmative, les requêtes n et n-1 sont permutées lors de l'étape E404, de façon à maintenir un ordonnancement des requêtes par ordre de fréquence décroissante. Au cours de l'étape suivante E405, on vérifie si la requête n, devenue n1 à l'étape précédente E404, fait partie des quelques requêtes les plus fréquentes en comparant le contenu du compteur C ffréquence d'apparition) à un seuil prédéterminé Cmax Si tel est le cas, alors, lors de l'étape E406, on décide que le contenu transcodé selon la décision venant d'être prise sera stocké dans l'unité de stockage 5 du serveur 1, à moins que l'étape E405 n'ait permis de détecter que ce contenu avait déjà été transcodé et mémorisé tel quel lors d'un traitement antérieur de la requête considérée. Dans ce cas, l'étape de transcodage E207 de la figure 2 n'est pas exécutée. Si, au contraire, cette requête ne se trouve pas en haut de la liste (requêtes les plus fréquentes), alors le traitement de la requête est terminé ce qui met fin à l'algorithme de la figure 4a. De retour à la figure 3c, dans le cas o la requête courante n'a pas déjà été traitée, mais qu'une requête présente en mémoire a été détectée comme étant similaire, on passe alors, après l'étape E302, à l'étape E306. Au cours de cette étape, une décision est prise de façon simplifiée et sera détaillée plus loin lors de la description faite en référence à la figure 3d. On décide que la requête en cours de traitement est similaire à une requête traitée antérieurement et mémorisée dans la mesure o les deux requêtes ont en commun au moins un descripteur de requête. Cependant, afin d'accélérer davantage le traitement d'une requête selon l'invention, on décidera, par exemple, qu'une requête est similaire à une requête antérieure si ces deux requêtes ont au moins deux descripteurs de requête en commun choisis parmi ceux illustrés à la figure 3b. La figure 3d illustrera un exemple de similarité des requêtes. La requête est alors insérée dans la mémoire 170 du moteur de décision 17, lors de l'étape E307, selon l'algorithme illustré sur la figure 4b qui sera décrit ultérieurement. Si aucune requête n'a été trouvée lors du test de l'étape E302, on passe alors à l'étape E309 o un calcul complet de la décision de transcodage est effectué selon l'algorithme iilustré sur la figure 3d décrite ci-après. La requête est alors insérée dans la mémoire 170 du moteur de décision 17, lors de l'étape E310, selon l'algoritUme de la figure 4b. La figure 3d illustre le processus de prise de décision pour l'adaptation des contenus dans le cadre du procédé de traitement d'une requête courante. Cette prise de décision est guidée par le résultat du test de l'étape E302 de la figure 3c. Dans le cas d'une requête courante identifiée comme étant similaire à une requête présente en mémoire 170, il sufffit de lire les paramètres d'adaptation 507 (figure 3b) lors de l'étape E351a. Au cours de cette étape, on se contente donc de prendre en compte les paramètres de codage qui vont être utilisés pour le codage des données à transmettre et qui ont déjà été déterminés antérieurement et stockés dans le module 170, en fonction de deux descripteurs de requête en commun. Dans l'exemple considéré, les descripteurs communs entre la requête en cours de traitement et la requete antérieure sont le descripteur 501 du contenu demandé par l'utilisateur et le descripteur 502 de la machine client 2. Si, au contraire, la requête soumise au dispositif 4 de la figure 1 n'est considérce comme étant similaire à aucune requête présente dans la mémoire 170, alors les paramètres d'adaptation 507 du contenu au client doivent être calculés à l'étape E351 b. Selon u n mode de réal isation très simple de l' invention, cette adaptation consiste à trouver la résolution spatiale r des images telle que r=min(rX'rOrig), o r,nax correspond à la taille de l'écran de la machine client, exprimée en nombre de pixels par ligne et par colonne et, rOrig correspond à la taille des images encodées dans la séquence vidéo demandée par l'utilisateur. On détermine ainsi un paramètre de codage des données à transmettre à la machine client en fonction d'un descripteur qui caractérise la requete en cours de traitement. Les étapes suivantes E352 et E353 permettent d'adapter le contenu au descripteur de requete 504 (figure 3b), à savoir la bande passante du réseau de transmission, en détemminant un débit br pour le ré-encodage de la vidéo demandée. L'étape E352, consiste plus particulièrement à comparer la bande passante, br,ax, du réseau de transmission avec le débit représentant la séquence d'images compressées: brOrjg. Au cours de l'étape E353, on choisit, parmi un ensemble de valeurs de débit prédéfinies (multiples de 16 kilo bits par seconde, par exemple), une valeur br telle que: br = min(brr,aX, brOrig) Les étapes suivantes E354 à E357 prennent en compte un autre descripteur de requete, à savoir les préférences de l'utilisateur 503 (figure 3b). Tout d'abord, les étapes E354 et E355 prévoient d'adapter la fréquence des images, fr, aux souhaits de l'utilisateur: fr,. L'étape E354 consiste ainsi à vérifier si l'inégalité suivante est bien respectée fru dans la séquence d'images compressées. Dans la négative, à l'étape E355, on choisit parmi un ensemble de valeurs de fréquences prédéfinies (5, 10, 15, 20, 25, 30 images par seconde, par exempie) une valeur frtelle que: fr = min(fru,fr,,lax). Dans l'amrmative, on s'intéresse aux étapes suivantes E356 et E357 au cours desquelles on détermine la résolution spatiale des images à transmettre en fonction des préférences de l'utilisateur. L'étape E356 consiste ainsi à vérifier si l'inégalité suivante est bien respectée rU raX, o r,laX correspond à la résolution spatiale caloulée à l'étape E351b ou lue à l'étape E351a et, o r'X correspond à la résolution souhaitée par l'utilisateur. Dans la négative, au cours de l'étape E357, on choisit parmi un ensemble de valeurs de résolutions prédéfinies (sub-QCIF, QCIF, CIF, par exemple) une valeur rtelle que: r = min(rU,r,,x). On notera que le format CiF ou format intermédiaire commun (connu en temminologie anglo-saxonne sous le terme "Common Intermediate Format") définit des tailles d'images de 352 colonnes par 288 lignes. De ce format dérivent les formats QCIF et sub-QCIF. Le format QCIF ("Quarter-Common Intermediate Format" en terminologie anglo-saxonne) définit une résolution spatiale de 176 colonnes par 144 lignes. Le format Sub-QCIF ("Sub-Quarter-Common Intermediate Format" en terminologie anglo-saxonne) déflnit, quant à lui, une résolution spatiale de 128 colonnes par 96 lignes. Si l'inégalité précitée est respectée, on passe à l'étape E358. Au cours de cette étape, tous les paramètres ou descripteurs de la décision 508 ayant été calculés précédemment, ceux-ci sont stockés, d'une part, dans l'unité 6 du dispositif 4 et, d'autre part, dans le module 170 à la fin de la liste de requêtes déjà présentes. Le contexte de la requête 500 et les paramètres intermédiaires d'adaptation au client 507 sont également stockés dans ce module 170. Le stockage de la décision est réalisé lors de l'étape E311 (figure 3c) pour le calcul complet (nouvelle requête) et, lors de l'étape E308, pour la prise de décision simplifiée (requête similaire). La figure 4b illustre le fonctionnement de la mémoire 170 du moteur de décision 17 et, notamment, l'insertion en mémoire (étape E307 de la figure 3c) d'une requête considérée comme similaire à une requête n présente en mémoire. Sur la figure 4b, la première étape E420 correspond à l'instant o la requête courante est identifiée comme une requête similaire à une requête n présente en mémoire. Au cours de l'étape suivante E421, on examine si la dernière place dans la mémoire 170 est inoccupée (compteur 505 égal à 0). Dans l'affirmative, on passe directement à l'étape E423. Dans la négative, l'étape suivante E422 remet à zéro les champs de la requête se trouvant à la fin de la liste pour effacer celle-ci de cette liste. L'effacement des requêtes les plus anciennes sera décrit ultérieurement en référence à la figure 4c. La place ainsi libérée permet d'insérer la requête courante à ia fin de la liste lors de l'étape suivante E423. Lors de l'étape E424, on recopie, à partir de la requête similaire n, les paramètres d'adaptation au client stockés dans l'unité 507 du moteur de décision 17. A l'étape E425,1'initialisation du compteur 505 est effectuée et la mise à jour de la date 506 de la requête est effectuée à l'étape E426. La dernière étape E427, vise à sauvegarder la décision de transcodage 508 (figure 3b) obtenue à l'étape E308 de la figure 3c par le module d'optimisation 175 du moteur de décision 17 Le procédé d'insertion d'une requête entièrement nouvelle (étape E310 de la figure 3c), suit le même algorithme, à l'exception de l'étape E424 qui est remplacée par une étape de récupération des paramètres d'adaptation au client issus du calcul effectué par le module 175 du moteur de décision 17, lors de l'étape E309. La figure 4c illustre la gestion de la mémoire 170 du moteur de décision 17 et, notamment, l'élimination des requêtes les plus anciennes. Ainsi, en commençant par la requête la moins probable disposée en fin de liste, la première étape E440 consiste à lire sa date d'entrée en mémoire dans la zone mémoire 506 (figure 3b). Au cours de l'étape suivante E441, on examine si la différence entre la date courante et la date lue précédemment est supérieure à un délai prédéfini (par exemple quelques jours ou quelques semaines). Dans la négative, on passe alors à l'étape suivante E442 qui teste si la requête traitée est la dernière requête de la liste. Si c'est la dernière, le traitement est terminé. Sinon, lors de l'étape E443, la date d'entrce en mémoire de la requête suivante dans la liste (avec un compteur 505 supérieur) est lue et le test pratiqué à l'étape E441 est de nouveau exécuté. Ce processus est réitéré tant que l'on n'a pas atteint la demière requête ou que le test sur le délai est validé. Si la requête en cours de traitement s'avère trop ancienne, alors, lors de l'étape E444, tous les champs 501 à 508 (figure 3b) associés à cette requête sont mis à zéro. L'étape suivante E445 effectue ensuite un nouveau tri de la liste, en partant de la requête la plus fréquente pour aller à la requête la moins fréquente. L'algorithme de la figure 5 comporte différentes instructions ou portions de code logiciel correspondant à des étapes du procédé de transcodage selon l'invention. Le programme informatique qui est basé sur cet algorithme est mémorisé dans l'unité de stockage temporaire de données 6 de la figure 1 et exécuté par l'unité 18 sous le contrôle de l'unité de commande 11. Ce programme fait partie du programme "Progr" précité en référence à la figure 2 et est également stocké dans l'appareil de la figure 6. L'exécution du programme infommatique basé sur cet algoritUme va mettre en _uvre le procédé pemmettant d'utiliser la décision de transcodage obtenue précédemment en vue d'effectuer un transcodage adapté des données à transmettre à la machine client. La figure 5 illustre les opérations de transcodage ou d'adaptation du contenu qui sont effectuées par le module de transcodage 18 de la figure 1, suite à I'émission de la décision de transcodage prise par le moteur de décision 17 au cours de l'une des étapes E304, E307 ou E310 de la figure 3. L'étape E500 de la figure 5 reprend cette étape et est suivie d'une étape E501 au cours de laquelle la décision est stockée temporairement dans l'unité de stockage temporaire 6 du dispositif 4 de la figure 1. A l'étape suivante E502, le module de transcodage 18 récupère l'identifiant du contenu stocké préalablement dans l'unité temporaire 6 lors de l'exécution de l'étape E201 de la figure 2. Cet identifiant lui permet alors d'accéder au contenu se trouvant dans l'unité de stockage 5. Comme on l'a vu précèdemment, ce contenu est stocké sous une forme compressée. Au cours de l'étape suivante E503, on décompresse ce contenu et on le conserve durant le transcodage dans l'unité temporaire 6 (étape E504). Ensuite, le module de transcodage 18 récupère dans l'unité 6 (étape E505) la décision de transcodage émise par le module 12 lors de l'étape E500 et stockée lors de l'étape E501. Cette décision contient les nouveaux paramètres de codage ettou ceux déjà calculés antérieurement et stockés. Ces paramètres sont utilisés pour le ré-encodage du contenu intervenant à l'étape E506. Ce contenu transcodé est ensuite transmis à la machine client 2 par I'intermédiaire de l'unité de transmission/réception 19 du dispositif 4, comme indiqué précédemment en référence à l'étape E208 de la figure 2. En référence à la figure 6, est décrit un exemple d'appareil programmable mettant en _uvre l'invention. Cet appareil est adapté à traiter des données numériques multimédia en vue de les transmettre. Selon le mode de réalisation choisi et représenté à la figure 6, un appareil mettant en aeuvre l'invention est par exemple un microordinateur 600 ou une station de travail connecté à dmérents périphériques, par exemple une caméra numérique 601 (ou un scanner, ou tout moyen d'acquisition ou de stockage d'image) relice à une carte graphique et fournissant à l'appareil des données à adapter et à transmettre. 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é de commande 11 de la figure 1, - une mémoire morte 604, pouvant comporter le programme "Progr", - une mémoire vive 606, comportant des registres 607 adaptés à enregistrer des variables crcoes et modifiées au cours de l'exécution du programme précité et notamment les variables rmax, rOn9' ru, br, brmax, brOng, fr, frmax, fru mentionnées en référence aux figures précédentes, - un écran 608 permettant de visualiser les données à traiter eVou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec le programme 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 le programme "Progr" précité, - un lecteur de disquette 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 communication 620, par exemple le réseau Internet, I'interface étant apte à transmettre et à recevoir des données. Dans le cas de donnces audio, I'appareil comprend en outre une carte d'entrée/sortie relice à un microphone qui sont tous deux non représentés. Le bus de communication 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, I'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 de ce micro ordinateur 600. Le code exécutable du programme noté "Progr" permettant à l'appareil programmable de mettre en _uvre les procédés de traitement et de décision quant à l'adaptation du contenu (figures 2, 3b, 3c, 4a-c) et d'adaptation du contenu (figure 5) selon l'invention, peut être stocké par exemple dans le disque dur 612 ou en mémoire morte 604 comme représenté sur la figure 6. Bien qu'un seul programme soit identifié, il est possible d'avoir plusieurs programmes ou sous programmes pour mettre en _uvre l'invention. Selon une variante, la disquette 616, peut contenir des données compressoes et stockées ainsi que le code exécutable du ou des programmes selon l'invention qui, une fois lu par l'appareil 600, sera stocké dans le disque dur 612. En seconde variante, le code exécutable du ou des programmes pourra être reçu par l'intermédiaire du réseau de communication 620, via l'interface 618, pour être stocké de façon identique à celle décrite 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 programme dont l'exécution permet la mise en _uvre du procédé selon l'invention. De manière plus générale, le programme pourra être chargé dans un des moyens de stockage de l'appareil 600 avant d'être exécuté. L'unité centrale 603 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 612 ou 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, sont transférés dans la mémoire vive RAM 606 qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables nécessaires à la mise en _uvre de l'invention. li convient de noter que l'appareil de communication comportant un dispositif selon l'invention peut également être un appareil programmé. Cat appmil ntien1 alom la code du ou des pgmmes Piques par example age dans un du# if appR-on sp6#que (ASIC). On noiem qua l'appamil de la figure 0 qu[ oontient le pmgmmme "Porgy' pcAdemment mencnnd pout 61m, dans le cads Dune shlu de communication du type clien1-seeur, le dispositif 4 de la figure 1. REVENDICATIONS 1. Procédé de traitement d'une requête d'obtention de données numériques multimédia, ladite requête comportant plusieurs descripteurs caractérisant celle-ci, caractérisé en ce que ledit procédé comporte les étapes suivantes: - analyse des descripteurs caractérisant la requête en cours de traitement, - comparaison du résultat de l'analyse avec les descripteurs d'autres requêtes traitées antérieurement, -en fonction du résultat de la comparaison, décision quant à savoir si ia requête en cours de traitement est: identique à une requête traitée antérieurement, en ce sens que les deux requêtes comportent les mêmes descripteurs de requête, 15. similaire à une requete traitée antérieurement, en ce sens que les deux requêtes ont en commun au moins un descripteur de requête, nouvelle par rapport aux requetes traitées antérieurement. 2. Procédé selon la revendication 1, caractérisé en ce que la requete en cours de traitement est considérée comme similaire à une requete antérieure lorsque les deux requetes ont en commun seulement certains descripteurs de requete. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que, lorsque la requete en cours de traitement est considérée comme similaire à une requête antérieure, ledit procédé comporte une étape de prise en compte d'au moins un paramètre de codage qui va être utilisé pour le codage des donnces et qui a déjà été déterminé antérieurement en fonction dudit au moins un descripteur de requête en commun avec la requête antérieure. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que, lorsque la requête en cours de traitement est considérée comme similaire à une requête antérieure traitée, ledit procédé comporte une étape de détermination d'au moins un paramètre dit de codage qui va être utilisé pour le codage des données, ledit au moins un paramètre de codage étant déterminé en fonction d'au moins un descripteur caractérisant la requête en cours de traitement et qui n'est pas en commun avec la requête antérieure. 5. Procédé selon la revendication 1, caractérisé en ce que, lorsque la requête en cours de traitement est considérée comme identique à une requête antérieure, ledit procédé comporte une étape de prise en compte d'au moins un paramètre de codage qui va être utilisé pour le codage des données et qui a déjà été déterminé antérieurement en fonction d'au moins certains des descripteurs caractérisant la requête en cours de traitement. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte une étape de détermination quant à savoir si la requête courante a une fréquence d'apparition qui est supérieure à un seuil prédéterminé. 7. Procédé selon la revendication 6, caractérisé en ce que, lorsque la fréquence d'apparition de la requête courante est supérieure au seuil prédéterminé, ledit procédé comporte une étape ultérieure de stockage des données codées avec ledit au moins un paramètre de codage déterminé antérieu rement. 8. Procédé selon la revendication 1, caractérisé en ce que, lorsque la requête en cours de traitement est considérée comme nouvelle, ledit procédé comporte une étape de détermination d'au moins un paramètre de codage qui va être utilisé pour le codage des données, ledit au moins un paramètre de codage étant déterminé en fonction d'au moins un descripteur caractérisant la requête courante. 9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce que les étapes d'analyse, de comparaison et de décision sont effectuées dans un premier appareil de communication relié à un second appareil de communication par un réseau de communication. 10. procédé selon la revendication 9, caractérisé en ce qu'un descripteur de la requête courante comprend au moins certaines des caractéristiques du second appareil de communication. 11. Procédé selon la revendication 10, caractérisé en ce qu'une caractéristique du second appareil de communication est la capacité de calcul de cet appareil. 12. Procédé selon la revendication 10, caractérisé en ce qu'une caractéristique du second appareil de communication est la capacité mémoire disponible dans cet appareil. 13. Procédé selon la revendication 9, caractérisé en ce qu'un descripteur de la requête courante comprend au moins certaines des caractéristiques du réseau de communication. 14. Procédé selon la revendication 9, caractérisé en ce qu'un descripteur de la requête courante identifie les données multimédia à fournir au second appareil de communication. 15. Procédé selon la revendication 14, caractérisé en ce qu'un descripteur de la requête courante spécifie les préférences d'un utilisateur émetteur de la requête en termes de présentation des donnces. 16. Procédé selon les revendications 2, 10 et 14, caractérisé en ce que la requête est considérée comme similaire à une requête antérieure lorsque sont pris en compte comme descripteurs de requête communs les données multimédia demandées dans la requête en cours de traitement et au moins un autre descripteur de requête. 17. Dispositif de traitement d'une requête d'obtention de donnces numériques multimédia, ladite requête comportant plusieurs descripteurs caractérisant celle-ci, caractérisé en ce que ledit dispositif comporte: des moyens d'analyse des descripteurs caractérisant la requête en cours de traitement, -des moyens de comparaison du résultat de l'analyse avec les descripteurs d'autres requêtes traitées antérieurement, - des moyens de décision, en fonction du résultat de la comparaison, quant à savoir si la requête en cours de traitement est: identique à une requête traitée antérieurement, en ce sens que les deux requêtes comportent les mêmes descripteurs de requête, similaire à une requête traitée antérieurement, en ce sens que les deux requêtes ont en commun au moins un descripteur de requête, nouvelle par rapport aux requêtes traitées antérieurement. 18. Dispositif selon la revendication 17, caractérisé en ce que la requête en cours de traitement est considérée comme similaire à une requête antérieure lorsque les deux requêtes ont en commun seulement certains descripteurs de requête. 19. Dispositif selon la revendication 17 ou 18, caractérisé en ce que ledit dispositif comporte de moyens de prise en compte d'au moins un paramètre de codage qui va être utilisé pour le codage des données et qui a déjà été déterminé antérieurement en fonction dudit au moins un descripteur de requête en commun avec la requête antérieure. 20. Dispositif selon l'une des revendications 17 à 19, caractérisé en ce que ledit dispositif comporte des moyens de détermination d'au moins un paramètre dit de codage qui va être utilisé pour le codage des données, ledit au moins un paramètre de codage étant déterminé en fonction d'au moins un descripteur caractérisant la requête en cours de traitement et qui n'est pas en commun avec la requête antérieure. 21. Dispositif selon la revendication 17, caractérisé en ce que ledit dispositif comporte des moyens de prise en compte d'au moins un paramètre de codage qui va être utilisé pour le codage des données et qui a déjà été déterminé antérieurement en fonction d'au moins certains des descripteurs caractérisant la requête en cours de traitement qui est considérce comme identique à une requête antérieure. 22. Dispositif selon la revendication 21, caractérisé en ce qu'il comporte des moyens de détermination quant à savoir si la requête courante a une fréquence d'apparition qui est supérieure à un seuil prédéterminé. 23. Dispositif selon la revend ication 22, caractérisé en ce que led it dispositif comporte des moyens de stockage des données codées avec ledit au moins un paramètre de codage déterminé antérieurement, lesdits moyens stockant lesdites données lorsque la fréquence d'apparition de la requête courante est supérieure au seuil prédéterminé. 24. Dispositif selon la revendication 17, caractérisé en ce que ledit dispositif comporte des moyens de détermination d'au moins un paramètre de codage qui va être utilisé pour le codage des données, ledit au moins un paramètre de codage étant déterminé en fonction d'au moins un descripteur caractérisant la requête courante qui est considérée comme nouvelle. 25. Dispositif selon l'une des revendications 17 à 24, caractérisé en ce que les moyens d'analyse, de comparaison et de décision sont intégrés dans un premier appareil de communication relié à un second appareil de communication par un réscau de communication. 26. Appareil de communication, caractérisé en ce qu'il comporte un dispositif traitement d'une requête d'obtention de données multimédia selon l'une des revendications 17 à 25. 27. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé de traitement d'une requête d'obtention de donnces multimédia selon l'une des revendications 1 à 16. 28. Moyen de stockage d'informations amovible, partiellement ou totalement lisible par un ordinateur ou un microprocesseur comportant des instructions de code d'un programme d'ordinateur pour l'exécution des étapes du procédé de traitement d'une requête d'obtention de données multimédia selon l'une des revendications 1 à 16. 29. Programme d'ordinateur chargeable dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions ou des portions de code logiciel pour mettre en _uvre les étapes du procédé de traitement d'une requête d'obtention de données multimédia selon l'une des revendications 1 à 16, lorsque ce programme d'ordinateur est chargé et exécuté par l'appareil programmable.