FR 2912275 A1 20080808 FR 0700765 A 20070202 Procédé de transmission d'au moins un contenu représentatif d'un service, depuis un serveur vers un terminal, dispositif et produit programme d'ordinateur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui de la création et de la transmission de contenus multimédia sur un terminal de radiocommunication, par exemple de type radiotéléphone, PDA (en anglais Personal Digital Assistant , en français assistant numérique personnel ), ordinateur portable, etc. On entend notamment par contenu multimédia un ensemble composé d'au moins une scène graphique animée, encore appelée scène multimédia, et d'une série de commandes permettant de faire évoluer cette scène d'un état à un autre. Une scène multimédia correspond notamment à l'agencement d'un ensemble d'objets graphiques dans le temps et dans l'espace, avec lesquels l'utilisateur du terminal de radiocommunication peut interagir. Cet agencement est décrit en utilisant un vocabulaire dépendant du format de description de scène. Le vocabulaire de scène peut être utilisé dans des descriptions textuelles ou dans des descriptions binaires. Dans une description textuelle au format XML, les mots du vocabulaire sont les noms des éléments utilisés dans la description. Dans une description binaire, les mots sont les objets binaires utilisés dans la description. L'invention trouve des applications dans tous les domaines nécessitant une représentation des signaux sous forme d'un agencement spatio-temporel d'objets graphiques, avec interactivité. Notamment, l'invention s'applique aux formats de description de scènes graphiques déjà connus tels que le MPEG-4/BIFS (en anglais Binary Format Scene , en français format binaire pour scène ), le SVG (en anglais Scalable Vector Graphics , en français graphiques vectoriels adaptables ), le SMIL (en anglais Synchronized Multimedia Integration Language , en français langage d'intégration multimédia synchronisés ), le XHTML (en anglais eXtensible HyperText Markup Language , en français langage de balisage hypertexte extensible ), etc. 2. Art antérieur Actuellement, il existe plusieurs dispositifs de transformation de description de scène multimédia textuelle en contenus visualisable par un utilisateur, parmi lesquels : • des dispositifs de type Encodeur qui, à partir d'une description textuelle, construisent un contenu binaire équivalent. • des dispositifs de type Compilateur qui, à partir d'un assemblage de symboles, de mots clés et de règles (i.e., un langage informatique), permettent de décrire des instructions à un environnement d'exécution qui construira un contenu binaire équivalent, • des dispositifs de type Moteur de publication dynamique qui, à partir de documents, les interprètent pour envoyer un contenu à un utilisateur. Parmi les techniques citées ci-dessus, la plus usitée est du type Encodeur. Elle ne fait que traduire un ensemble d'instructions multimédia exprimées en un format F1 en un autre format F2, lequel format F2 étant en général plus compressé que le premier format F1. Un inconvénient de cette technique réside dans le fait qu'elle ne permet pas à l'auteur de traduire un ensemble de scènes graphiques en un code exécutable qui génèrera des contenus suivant le contexte d'exécution. Cette technique n'est donc pas adaptée à la génération de contenus dynamiques. La technique la plus avancée définit comment un dispositif de type Moteur de publication dynamique interprète un document et construit un contenu destiné à être diffusé directement, c'est-à-dire dans le format utilisé pour la partie description de scène du document initial. Dans les exemples ci-après, un tel format est par exemple un format textuel XML ou HTML débarrassé des scripts à exécuter sur le serveur. Par exemple, les technologies Server Pages (e.g., Active Server Pages Tm ou XML Server Pages) fournissent ur:I environnement de développement de scripts serveur pour créer des applications serveur pour le Web, à la fois dynamiques et interactives. L'auteur peut associer des pages XML ou HTML et les commandes de script pour créer des pages Web interactives ou de puissantes applications basées sur le Web. La plupart des technologies de pages actives (ASP, PHP, ...) reposent sur un code interprété, dont l'exécution requiert beaucoup de ressources pour fournir la réponse. Les technologies Java Server Pages (JSP) se distinguent par le fait qu'elles sont compilées seulement dans le cas où le script Java Server Pages a été mis à jour. Ces technologies JSP sont plus rapides à l'exécution que les technologies entièrement interprétées. Cependant, dans tous les cas, l'interprétation du document est faite au moment de la requête utilisateur, ce qui rend délicate une validation a priori de l'ensemble des contenus. De plus, ces techniques ne permettent pas de valider a priori un "service dynamique", c'est à dire un ensemble de contenus dynamiques et de règles de navigation qui relient lesdits contenus dynamiques, et encore moins le fonctionnement du système de génération de contenus au complet. En outre, l'interprétation au moment de la requête utilisateur rend délicate ou impossible toute gestion des médias utilisés dans le service, surtout si les références à ces médias sont créées par des commandes de script. Enfin, un autre inconvénient des technologies JSP tient au fait que tous les mots du vocabulaire de la description du service doivent être des mots du langage final. Il n'est pas possible de faire des extensions, dans la description du service, qui ne seraient pas compatibles avec le langage final. Il existe aussi des méthodes de conception d'applications reposant uniquement sur un langage de programmation. Il est effectivement possible d'inclure dans un programme informatique une série de modules dont les fonctions recouvrent : - la création d'une scène multimédia en mémoire ; -la gestion de l'interactivité, de l'animation et du rendu de ladite scène ; - le dialogue avec un serveur et l'interprétation des réponses dudit serveur. Ces approches permettent de créer tout type de service, y compris un mélange très complexe de présentation de données et de calculs, ce qui peut être nécessaire dans une application de type jeu. Par contre, ces approches sont extrêmement coûteuses en temps de développement et se prêtent mal à une diffusion sur un large parc de terminaux différents, car chaque application doit être testée sur chaque type de terminal. Enfin les techniques basées sur des dispositifs de type Compilateur permettent seulement de générer un code exécutable, les langages informatiques utilisés en entrée décrivent souvent ,des instructions élémentaires interprétées et exécutées par l'environnement d'exécution et non des règles de création de contenus, et ne peuvent donc pas être utilisées dans le cadre de la création de contenus dynamiques. 3. Objectifs de l'invention L'invention a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Le procédé, selon au moins un mode de réalisation de l'invention, permet à un auteur de valider un service dynamique, c'est à dire un ensemble de contenus dynamiques et de règles de navigation qui relient lesdits contenus dynamiques, avant de déployer ce service. On parle alors de "validation a priori". Le procédé, selon au moins un mode de réalisation de l'invention, permet également à un auteur d'assurer un fonctionnement optimal du code exécutable représentant un service dynamique en réduisant le poids des étapes intermédiaires, et en particulier en réduisant le volume de chaînes de caractères à traiter pour l'exécution de ce service. De plus, le procédé, selon au moins un mode de réalisation de l'invention, permet d'obtenir un gain en expressivité sur la création de contenus, car l'auteur du service bénéficie d'un mécanisme intégré lui permettant de traiter de façon simultanée la présentation des contenus, l'interprétation des instructions exécutées au sein de l'environnement d'exécution et la génération de ces contenus sur un mode dynamique. Le procédé, selon au moins un mode de réalisation de l'invention, permet d'obtenir une réduction de la mémoire et de l'utilisation des ressources de calcul à l'exécution d'un service dynamique en ne stockant en mémoire et en n'exécutant que le code exécutable généré. Contrairement aux moteurs de publication classique, l'interpréteur des documents en code exécutable n'est pas nécessaire lors de l'exécution. Avantageusement, le procédé, selon au moins un mode de réalisation de l'invention, permet d'obtenir un gain dans l'implémentation du système de publication : l'utilisation d'un dispositif intégrant un Compilateur, un Encodeur et un Moteur de publication permet de simplifier le processus d'édition dudit contenu. Cela assure à l'auteur d'avoir un environnement intégré, lui permettant en une seule interface de générer des services dynamiques et de valider, sans déploiement sur une plate-forme serveur de publication, la complexité, la cohérence et le fonctionnement de ces services. Le procédé, selon au moins un mode de réalisation de l'invention, permet également d'obtenir une compatibilité avec les environnements d'exécution classiques, en étant capable de générer un code exécutable compatible avec n'importe quel environnement d'exécution compatible (i.e., code exécutable JAVA sur plate-forme J2EE). Le procédé, selon au moins un mode de réalisation de l'invention, permet aussi de rajouter dans la description des extensions incompatibles avec le langage final. Ces extensions sont destinées à l'optimisation du service ou d'une des phases du service, et sont supprimées par la phase de génération binaire. Cette flexibilité importante permet d'exprimer simplement pour l'auteur des informations utiles pour optimiser l'exécution du code généré lors de l'exécution du service : par exemple instructions de cache serveur, factorisation d'un sous-ensemble de scènes inclus dans plusieurs autres scènes. Le procédé, selon au moins un mode de réalisation de l'invention, permet d'implémenter une gestion fine des médias référencés par le service, grâce à l'interprétation systématique de toutes les parties du service, y compris les références auxdits médias. De plus, le procédé, selon au moins un mode de réalisation de l'invention, permet d'augmenter le nombre d'erreurs de conceptions détectables pendant la phase de conception et permet donc une meilleure validation a priori des services : lors de la phase de transformation de la description textuelle du service dynamique en code exécutable, les deux parties de la description textuelle, à savoir la description de scène et les instructions de programme, sont traduites et fusionnées en une même description qui permet une analyse statique et globale des liens entre lesdites deux parties, alors que pour les techniques existantes, le seul moyen de vérifier ces liens est d'exécuter un grand nombre de requêtes de contenus dans l'environnement d'utilisation. Enfin, les techniques utilisées dans le procédé selon au moins un mode de réalisation de l'invention permettent de réduire les coûts de développement en ne requérant pas de compétence avancée de programmation pour concevoir les services. De plus, un moteur de rendu générique peut être testé sur chaque type de terminal indépendamment du nombre des services qui utiliseront ce moteur de rendu générique. 4. Exposé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de transmission d'au moins un contenu représentatif d'un service, depuis un serveur vers un terminal. Selon l'invention, un tel procédé comprend : une phase préalable de préparation dudit service, comprenant : - une étape de fourniture dudit service par un créateur sous la forme d'une description textuelle comprenant une partie de texte et au moins une instruction de programme ; - une étape de traduction, dans un environnement de compilation, de ladite description textuelle dudit service en un programme de service, comprenant des instructions exécutables ; une phase de transmission dudit contenu vers ledit terminal, à réception d'une requête de ce dernier, comprenant : - une étape d'exécution dudit programme de service sur ledit serveur, délivrant ledit contenu sous la forme de données binaires; une étape de transmission desdites données binaires vers ledit terminal. Ainsi, le procédé selon l'invention permet de transmettre un contenu binaire représentatif d'un service à un terminal, en réponse à une requête de celui- ci, en ayant au préalable effectué une phase de préparation du service. Cette phase de préparation consiste tout d'abord à créer le service en question, par l'intermédiaire d'un créateur de service, et à fournir ce service au serveur de transmission. Cette étape de fourniture consiste à mettre à la disposition du serveur de transmission un service, soit créé "en interne", au niveau du serveur lui-même, dans un environnement de conception de service, soit créé dans un environnement de conception externe au serveur, comme un ordinateur ou un serveur dédié spécifiquement à la création de services. Dans le premier cas, l'étape de fourniture consiste à transmettre, à l'intérieur d'un même serveur, un service, et dans le second cas, cette étape consiste à fournir au serveur un service créé de façon "externe" à ce serveur. Avantageusement, le service créé se présente sous la forme d'une description textuelle comprenant une partie de texte et au moins une instruction de programme. Une fois le service ainsi créé et mis à la disposition du serveur, celui-ci subit une étape de traduction, dans un environnement dit de compilation. Cette étape de traduction consiste à transformer la description textuelle du service en un programme de service, comprenant des instructions exécutables. Cette étape de traduction se déroule également dans le serveur de transmission. Cette phase de préparation du service, préalable à la transmission, permet un gain de temps considérable dans le traitement de la réponse à la requête du terminal, le service étant déjà pré-traité et "prêt" à être exécuté, sous la forme d'un programme de service. De plus, la création de ce programme de service permet, dans l'étape suivant d'exécution, de générer dynamiquement des données binaires, sans passer par un langage tel que XML, ce qui permet d'économiser notablement la mémoire nécessaire pour la transmission d'un contenu représentatif d'un service. La phase de transmission du contenu représentatif d'un service comprend elle-même plusieurs étapes, déclenchées à la réception d'une requête provenant du terminal destinataire du contenu. La première étape consiste d'abord à exécuter, sur le serveur, le programme de service, délivrant, ou générant, ainsi un contenu sous la forme de données binaires. Ces données binaires ainsi générées sont ensuite transmises au terminal en réponse à sa requête. Préférentiellement, ladite étape d'exécution dudit programme de service sur ledit serveur comprend une sous-étape d'identification d'un contexte d'exécution associé audit terminal, fournissant au moins une caractéristique dudit terminal, qui est prise en compte pour la génération desdites données binaires transmises audit terminal. Ainsi, le serveur de transmission va prendre en compte certaines caractéristiques du terminal, par exemple contenues dans la requête émise par celui-ci, pour créer un environnement d'exécution du programme de service, et ainsi adapter l'exécution au terminal en question. Cette étape d'identification d'un contexte d'exécution permet ainsi d'optimiser l'étape d'exécution du programme de service, en tenant compte de caractéristiques du terminal. Le serveur prendra également en considération des caractéristiques liées au service pour créer ce contexte d'exécution. Avantageusement, lesdites étapes de traduction et d'exécution mettent en oeuvre une même interface de programmation, faisant appel à un vocabulaire de scène utilisé dans ladite description textuelle dudit service. Ainsi, l'étape de traduction va notamment considérer que la description textuelle du service est conforme à un vocabulaire de scène. Ainsi, les termes appartenant à ce vocabulaire vont servir à traduire du texte en instructions, par l"intermédiaire d'une interface de programmation. Par exemple, l'étape de traduction va utiliser un dictionnaire comprenant les termes du vocabulaire de scène et les instructions correspondantes. De plus, le programme de service est lui aussi conforme à ce vocabulaire de scène. Ainsi, l'étape d'exécution du programme de service va se servir de cette même interface de programmation, faisant appel au même vocabulaire de scène, pour interpréter les instructions et les exécuter. Selon un aspect particulier du procédé selon l'invention, ledit vocabulaire de scène comprend des éléments faisant référence à au moins un type de média. Ainsi, le vocabulaire de scène permet de faire référence par exemple à de l'audio ou de la vidéo. Selon un autre aspect du procédé selon l'invention, au moins une desdites instructions de programme porte sur au moins un objet multimédia. Par exemple, les instructions de programme peuvent permettre de créer un objet vidéo (par exemple un "clip"), ou un objet audio (par exemple un intermède musical ou "jingle"). Selon un mode de réalisation particulier, au moins une desdites instructions de programme porte sur au moins une adresse pointant sur au moins un objet multimédia ou un autre contenu. Ainsi, les instructions de programme permettent de faire appel à des objets multimédias (audio, vidéo, ...) ou des contenus qui ne sont pas décrits directement dans le service, mais qui sont accessibles par l'intermédiaire d'adresses, par exemple une "url". De façon avantageuse, ladite étape de transmission comprend une étape de multiplexage desdites données binaires dudit contenu, à la sortie dudit serveur, avec des données binaires générées indépendamment dudit contenu. Ainsi, le procédé selon l'invention permet au serveur de transmettre au terminal un contenu représentatif d'un service, dans lequel ont été intégrées d'autres données, par exemple des données audio ou vidéo. Ces données binaires sont multiplexées avec les données de service pour former un contenu "complet" à transmettre au terminal. Selon encore un mode de réalisation particulier, lesdites étapes de transmission et d'exécution sont effectuées en parallèle de façon que lesdites données binaires soient transmises vers le terminal au fur et à mesure de leur génération. Ainsi, la parallélisation de ces étapes d'exécution et de transmission permet une transmission en mode continu, encore appelé "streaming" en anglais, du contenu représentatif du service, au fur et à mesure de la génération des données binaires sur le serveur. Cela permet notamment de commencer à transmettre du contenu au terminal même si le programme de service en entier n'a pas encore été exécuté sur le serveur. Avantageusement, ladite phase préalable de préparation dudit service comprend une étape de contrôle dudit vocabulaire de scène, avant ladite étape de traduction, vérifiant que ladite partie de texte correspond à des éléments dudit vocabulaire de scène. Ainsi, cette étape de contrôle permettra de valider que le service a été créé en respectant le vocabulaire de scène choisi, et permettra de faciliter la traduction de la description textuelle du service, soit en éliminant les éléments de la description non conformes au vocabulaires, soit en les corrigeant. De plus, selon un mode de réalisation particulier, ladite phase préalable de préparation dudit service comprend une étape de contrôle desdites instructions de programme vérifiant que la ou lesdites instructions de programme correspondent à des instructions de programme d'ordinateur directement transformables en séquences de code binaire aptes à être exécutées par ledit serveur. Cette étape de contrôle permet quant à elle de vérifier que les instructions de programme présentes dans la description du service sont conformes à des instructions exécutables par serveur. La encore, cette étape facilite l'étape de traduction. Avantageusement, ladite phase préalable de préparation dudit service comprend une étape de transformation de ladite partie de texte en instructions de programme utilisant ladite même interface de programmation. Ainsi, cette étape permet de transformation utilise la même interface de programmation que celle utilisée dans les étapes de traduction et d'exécution. Enfin, selon encore un mode de réalisation particulier, ladite phase préalable de préparation dudit service comprend une étape de contrôle de cohérence vérifiant que lesdites instructions de programme de ladite description sont cohérentes avec celles provenant de ladite étape de transformation. Ainsi, le procédé peut vérifier que les instructions ne font pas appel à des éléments non présents dans la description textuelle par exemple. De plus, cette étape peut vérifier que l'étape de transformation a généré des instructions conformes aux instructions présentes à la création du service. L'invention concerne également un dispositif de transmission d'au moins un contenu représentatif d'un service, depuis un serveur vers un terminal. Selon l'invention, un tel dispositif comprend : des moyens préalables de préparation dudit service, comprenant : - des moyens de réception dudit service fourni par un créateur sous la forme d'une description textuelle comprenant une partie de texte et au moins une instruction de programme ; - des moyens de traduction, dans un environnement de compilation, de ladite description textuelle dudit service en un programme de service, comprenant des instructions exécutables ; des moyens de transmission dudit contenu vers ledit terminal, à réception d'une requête de ce dernier, comprenant : - des moyens d'exécution dudit programme de service sur ledit serveur délivrant ledit contenu sous la forme de données binaires ; - des moyens de transmission desdites données binaires vers ledit terminal. Notamment, un tel dispositif est apte à mettre en oeuvre le procédé de transmission selon l'invention, tel que décrit précédemment. Un tel dispositif est par exemple un serveur de service apte à transmettre un contenu représentatif d'un service à un terminal. L'invention concerne encore un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de transmission tel que décrit précédemment. 5. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre un exemple de conception d'un service dynamique selon un mode de réalisation de l'invention ; la figure 2 illustre un exemple de transmission d'un service dynamique conçu selon l'exemple de la figure 1, selon un mode de réalisation 5 particulier de l'invention ; la figure 3 présente les différentes étapes du procédé selon un mode de réalisation particulier de l'invention ; 6. Description de l'invention 6.1 Principe général de l'invention 10 Le principe général de l'invention consiste à décrire un procédé de transformation d'une description de scènes multimédia en code système, l'exécution de ce code système générant alors des données multimédia binaires en un contenu encore appelé service dynamique. Le procédé selon l'invention consiste à fournir à un auteur des outils pour 15 générer un code exécutable directement compréhensible par un système informatique sur la base d'une description de scène. L'exécution de ce code va alors produire un ensemble de contenus qui dépendra du contexte d'exécution dudit code, c'est à dire à la fois du service et du client demandant à utiliser ce service. Ces contenus sont dits dynamiques. 20 On présente les différentes étapes du procédé selon un mode de réalisation particulier de l'invention, en relation avec la figure 3. Les différentes étapes peuvent être regroupées en 2 phases : une phase de préparation 31 ; une phase de transmission 32. 25 La première phase 31 de préparation comprend deux étapes, permettant de générer un programme de service. La première étape 311 de fourniture d'un service consiste à concevoir et créer un service, destiné à être utilisé par un terminal en ayant fait la requête. Cette étape peut être réalisée en interne dans le serveur de transmission, ou en 30 externe. Dans les deux cas, un service, représenté sous la forme d'une description textuelle, comprenant une partie cle texte et au moins une instruction de programme, est mis à la disposition du serveur pour la deuxième étape 312 de traduction de ce service en un programme de service. Cette étape consiste à transformer la description textuelle du service en instructions exécutables par le serveur, sous la forme d'un programme de service. La deuxième phase 32 de transmission comprend également deux étapes, permettant, en réponse à une requête d'un terminal, de fournir un contenu binaire et de le transmettre au terminal. La première étape 321 d'exécution du programme de service consiste à transformer le programme de service en données binaires en l'exécutant. Ces données binaires forment le contenu à transmettre au terminal, dans une deuxième étape 322 de transmission. On présente ci-après, en relation avec la figure 1, l'étape de conception d'un service, selon un mode de réalisation particulier de l'invention. De manière générale, un outil auteur nommé Studio (11) crée et/ou agit sur une description textuelle de service dynamique (12). La description dudit service dynamique (12) est ensuite compilée par un Interprète (13), lequel se base sur un Dictionnaire (14) de correspondance entre les éléments déclarés dans la description de services dynamiques et les instructions de programme correspondantes. Le résultat de la compilation est un service dynamique (15) en code exécutable (16). La figure 2 représente l'étape de transmission d'un service dynamique conçu comme décrit précédemment, selon un mode de réalisation particulier de l'invention. Le code exécutable (16) du service dynamique (15) est placé dans un environnement du Serveur de services (23). Le terminal (20) envoie une requête (21) de contenu au Serveur de service (23). Le Serveur de service (23) crée un contexte d'exécution (24) pour le client et le service demandé. Au sein de ce contexte d'exécution (24), le code exécutable (16) du service dynamique (15) est exécuté pour générer la réponse (22), qui est alors transmise au terminal (20) par le serveur (23). 6.2 Conception d'un service dynamique 6.2.1 Premier mode de réalisation On présente ci-après les différentes étapes de la conception d'un service dynamique, en relation avec la figure 1, selon un premier mode de réalisation de l'invention. Un auteur va réaliser grâce à l'outil Studio (11) des présentations multimédia au sein desquelles les objets graphiques ont des comportements dynamiques. L'auteur exprime aussi des règles de navigation permettant à un utilisateur de naviguer entre les différentes présentations. L'ensemble des contenus dynamiques et les règles de navigation qui les relient sont désignés ci-après par le terme de service dynamique. La forme de la description du service dynamique (12) dans l'étape de conception est uneforme textuelle, clans laquelle des instructions de programme sont insérées dans une description textuelle déclarative utilisant un vocabulaire de type LASeR. Un outil Interprète (13), en charge notamment de la génération binaire de la description textuelle des contenus, dynamiques, prend en entrée les éléments graphiques, les agencements graphiques et les règles de navigation exprimés par l'auteur. Cet Interprète (13) construit un ensemble de codes exécutables (16), encore appelées données binaires, sur la base d'un Dictionnaire d'instructions et de règles (14), encore appelé vocabulaire, qui permet : - de traduire un élément graphique élémentaire en un ensemble de commandes élémentaires interprétées et exécutées par l'environnement d'exécution du Serveur de services (23) de la figure 2, - d'appliquer des règles de vérification de la cohérence de la description à un niveau sémantique, encore appelée étape de contrôle du vocabulaire. Il est à noter que ces vérifications ne sont pas possibles avec les descriptions syntaxiques, et non textuelles, par exemple de type DTD ( Document Type Definition pour Définition du type de document ) permettant de vérifier qu'un document XML (en anglais eXtensible Markup Language pour langage de balisage extensible ) est conforme à une syntaxe donnée, ou de type XSD ( XML Schema Definition pour Définition de schéma XML ), permettant de vérifier qu'un document XML est conforme à une syntaxe donnée, -d'appliquer d'autres règles de production de contenu, comme par exemple des règles de gestion des médias synchronisés avec la description de scène, permettant d'optimiser l'expérience utilisateur. L'ensemble de codes exécutables est alors inséré dans l'environnement d'exécution du Serveur de services (23). 6.2.2 Deuxième mode de réalisation Dans un mode de mise en oeuvre particulier de l'invention, la description textuelle de service dynamique (12) est soumise à une étape d'édition de texte par un concepteur de service désirant s'affranchir des limitations liées à l'outil auteur Studio (11). 6.2.3 Troisième mode de réalisation Dans un autre mode de mise en oeuvre de l'invention, la description textuelle de service dynamique (12) est constituée d'une description LASeR ML ( LASeR Markup Language ), c'est-à-dire de la déclaration du contenu d'une scène multimédia interactive au format LASeR, avec des éléments et des attributs de scène LASeR et des commandes de modifications de scène LASeR. Dans cette description, des instructions de programme Java sont insérées, telles que décrites ci-dessous dans un exemple : " y="O"/> Ces instructions Java peuvent faire référence à : - des éléments nommés de la description LASeR de la scène, c'est-à-dire les éléments possédant un attribut id dont la valeur est le nom de l'élément sous forme de chaîne de caractères ; - des éléments englobants l'endroit où sont insérées lesdites instructions Java ; - des méthodes appartenant à une bibliothèque de fonctions spécifiques permettant de créer des éléments LASeR, de manière à être capable, au sein de ces instructions, de créer des attributs ou des éléments et de les insérer à tout endroit pertinent de la scène ; - des méthodes appartenant à une bibliothèque de fonctions génériques utiles pour la conception de services multimédia dynamiques sur une variété de terminaux, parmi lesquelles : o récupérer des ressources sur des serveurs distants (client HTTP encapsulé), o manipuler des ressources stockées en cache (base de données), o retailler/transcoder des images sur ledit serveur de services, o obtenir des informations sur le terminal par décodage des informations de capacité du terminal. - des méthodes appartenant à toute bibliothèque spécifique aux besoins d'un service particulier, bibliothèque qui devra alors être présente dans l'environnement d'exécution clu service. Dans cette description, les délimitent les zones d'instructions de programme. La première zone correspond aux importations de paquetages contenant toutes les bibliothèques nécessaires, la seconde crée un objet permettant d'obtenir des propriétés, la troisième interroge la couleur de fond. Dans cette description, un attribut est décrit en XML, et sa valeur est définie en instructions de programme (ici en Java). Cela permet notamment à l'auteur de définir librement les éléments, les attributs et les contenus dans l'un ou l'autre des formalismes, voire même de les définir partiellement dans un formalisme et de les compléter dans un autre. Par exemple, l'extrait de description ci-dessous met en oeuvre une référence à un élément englobant une instruction de programme : 4text> Le Terminal (20) demande un contenu à un Serveur de services (23) suite à une interaction d'un utilisateur qui génère une requête (21). Le Serveur de services (23) sélectionne l'environnement d'exécution, définit le contexte d'exécution (24) et exécute le code exécutable (16), c'est à dire les différentes instructions contenues dans ce code. Ces différentes instructions permettent notamment de prendre en compte les différents paramètres suivants : - une logique du service, c'est à dire une logique correspondant au déroulement spécifique à un service ; - une logique de gestion du type du terminal client (20), avec adaptation possible du contenu de la description de scène en fonction des caractéristiques dudit terminal (20) ; - une logique de gestion des ressources externes nécessaires audit service, telles que l'accès à des bases de données externes ; - une logique de gestion des médias utilisés par ledit service, telle que par exemple le respect dune charte graphique, nécessitant l'utilisation de logos visuels ou sonores ; Ces différents paramètres peuvent être pris en compte dans un ordre variable en fonction du service, avec notamment la prise en compte à plusieurs reprises d'un même paramètre lors de l'exécution, en fonction de la prise en compte des paramètres précédents. L'exécution suit donc une logique de génération binaire de la description de scène résultant de la prise en compte des différentes logiques ci-dessus. Le serveur renvoie ensuite un contenu au terminal (20) qui décrit l'agencement spatio-temporel des objets graphiques, ce qui constitue la réponse (22). L'ensemble de ces étapes est alors répété autant de fois que nécessaire pour répondre aux requêtes successives de l'utilisateur. Dans un mode particulier d'implémentation du Serveur de services (23), une phase de multiplexage suit la phase de génération binaire. Au cours de la vie du service, un ensemble de paquets binaires de description de scène sont générés, et un ensemble de paquets contenant des trames de médias, en général audio ou vidéo, sont envoyés dans un même canal de communication. Cette phase de multiplexage contient une étape de planification de l'envoi des paquets qui ont été confiés au multiplexeur, puis une étape d'entrelacement des paquets des différents types d'une manière optimale pour l'expérience utilisateur. REVENDICATIONS 1. Procédé de transmission d'au moins un contenu représentatif d'un service, depuis un serveur vers un terminal, caractérisé en ce qu'il comprend : une phase préalable (31) de préparation dudit service, comprenant : - une étape de fourniture (311) dudit service par un créateur sous la forme d'une description textuelle comprenant une partie de texte et au moins une instruction de programme ; - une étape de traduction (312), dans un environnement de compilation, de ladite description textuelle dudit service en un programme de service, comprenant des instructions exécutables ; une phase de transmission (32) dudit contenu vers ledit terminal, à réception d'une requête de ce dernier, comprenant : - une étape d'exécution (321) dudit programme de service sur ledit serveur, délivrant ledit contenu sous la forme de données binaires; - une étape de transmission (322) desdites données binaires vers ledit terminal. 2. Procédé de transmission selon la revendication 1, caractérisé en ce que ladite étape d'exécution dudit programme de service sur ledit serveur comprend une sous-étape d'identification d'un contexte d'exécution associé audit terminal, fournissant au moins une caractéristique dudit terminal, qui est prise en compte pour la génération desdites données binaires transmises audit terminal. 3. Procédé de transmission selon l'une quelconque des revendications 1 et 2, caractérisé en ce que lesdites étapes de traduction et d'exécution mettent en oeuvre une même interface de programmation, faisant appel à un vocabulaire de scène utilisé dans ladite description textuelle dudit service. 4. Procédé de transmission selon la revendication 3, caractérisé en ce que ledit vocabulaire de scène comprend des éléments faisant référence à au moins un type de média. 5. Procédé de transmission selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'au moins une desdites instructions de programme porte sur au moins un objet multimédia. 6. Procédé de transmission selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'au moins une desdites instructions de programme porte sur au moins une adresse pointant sur au moins un objet multimédia ou un autre contenu. 7. Procédé de transmission selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite étape de transmission comprend une étape de multiplexage desdites données binaires dudit contenu, à la sortie dudit serveur, avec des données binaires générées indépendamment dudit contenu. 8. Procédé de transmission selon l'une quelconque des revendications 1 à 7, caractérisé en ce que lesdites étapes de transmission et d'exécution sont effectuées en parallèle de façon que lesdites données binaires soient transmises vers le terminal au fur et à mesure de leur génération. 9. Procédé de transmission selon l'une quelconque des revendications 3 à 8, caractérisé en ce que ladite phase préalable de préparation dudit service comprend une étape de contrôle dudit vocabulaire de scène, avant ladite étape de traduction, vérifiant que ladite partie de texte correspond à des éléments dudit vocabulaire de scène. 10. Procédé de transmission selon l'une quelconque des revendications 1 à 9, caractérisé en ce que ladite phase préalable de préparation dudit service comprend une étape de transformation de ladite partie de texte en instructions de programme utilisant ladite même interface de programmation. 11. Procédé de transmission selon la revendication 10, caractérisé en ce que ladite phase préalable de préparation dudit service comprend une étape de contrôle de cohérence vérifiant que lesdites instructions de programme de ladite description sont cohérentes avec celles provenant de ladite étape de transformation. 12. Dispositif de transmission d'au moins un contenu représentatif d'un service, depuis un serveur vers un terminal, caractérisé en ce qu'il comprend : des moyens préalables de préparation dudit service, comprenant : - des moyens de réception dudit service fourni par un créateur sous la forme d'une description textuelle comprenant une partie de texte et au moins une instruction de programme ;- des moyens de traduction, clans un environnement de compilation, de ladite description textuelle dudit service en un programme de service, comprenant des instructions exécutables ; des moyens de transmission dudit contenu vers ledit terminal, à réception d'une requête de ce dernier, comprenant : - des moyens d'exécution dudit programme de service sur ledit serveur délivrant ledit contenu sous la forme de données binaires ; - des moyens de transmission desdites données binaires vers ledit terminal. 13. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de transmission selon l'une au moins des revendications 1 à 11.