FR 2972321 A1 20120907 FR 1151744 A 20110303 PROCEDE ET SYSTEME DE GENERATION ET DE MISE A JOUR DE DONNEES STRUCTUREES DESTINEES A DES TERMINAUX MULTIMEDIA L'invention se rapporte au domaine technique de l'agrégation et de la mise en forme de contenus multimédia sur des terminaux multimédia. On désigne, ci-après, par « contenu multimédia » toute représentation numérique comprenant au moins une scène multimédia qui est généralement décrite par un document de scène spécifiant l'agencement, dans l'espace et dans le temps, des objets multimédia qui s'y trouvent. Plus spécifiquement, une scène multimédia est constituée d'une scène initiale pouvant intégrer une pluralité d'objets multimédia discrets (texte, éléments graphiques de base, animations par exemple) ou continus (contenu audio, contenu vidéo par exemple) ainsi qu'éventuellement des éléments de transformation de scène permettant de la faire évoluer d'un état à un autre soit dans le temps soit par une action interactive. Par ailleurs, on entend ici par « terminal multimédia », tout équipement utilisateur (mobile ou fixe) apte à recevoir et afficher une scène multimédia tels qu'un terminal mobile de communications (un téléphone, un Smartphone, un PDA par exemple), un ordinateur, un téléviseur, ou plus généralement un moyen d'affichage d'information multimédia (actualités, horaires transport). Les progrès technologiques des moyens de communications visent, en particulier, à développer les capacités des terminaux multimédia à supporter un service multimédia d'une qualité toujours meilleure. La visualisation d'une scène multimédia sur l'écran d'un terminal utilisateur ne cesse de susciter le besoin d'une mise à disposition de plus en plus fluide et rapide des contenus multimédia. Ce besoin est particulièrement ressenti dans le marché du multimédia sur les réseaux bas-débits, comme les réseaux sans-fil 3G, destiné à des terminaux à ressources réduites tels que les Smartphones ou les assistants numériques personnels (PDA). On entend par « ressources réduites » la capacité de la connectivité (3G, Wifi, câble par exemple), les codecs, la V007 B001 FR/TQD mémoire du terminal, et la puissance, par exemples, du terminal multimédia. Par conséquent, l'émergence des terminaux multimédia à ressources réduites a fait surgir les limites des techniques actuelles de mise à disposition des contenus multimédia. La mise à disposition d'un contenu multimédia comprend, notamment, - la génération de documents de scène : dans cette phase, une abstraction des scènes est faite à l'aide de différentes méthodes descriptives telles que BIFS (Blnary Format for Scene), XHTML (eXtensible HyperText Markup Language), SVG (Scalable Vector Graphics), Flash, SMIL (Synchronized Multimedia Integration Language). Cette phase comprend, en outre, l'adaptation du contenu généré aux contraintes liées aux terminaux multimédia; - la publication des documents de scène générés: la publication se fait dans un format spécifique selon un mode particulier (en broadcast, ou sur IP par exemple) jusqu'au dispositif de lecture et/ou de visualisation (browser, lecteur Flash, BIFS, par exemple) afin d'y être affiché en une scène multimédia; et - la gestion des modifications ou mises à jour des scènes multimédia affichées liées soit aux interactions utilisateur soit aux actions temporelles. Il existe un grand nombre de procédés antérieurs permettant d'agréger des données et de les fusionner au sein d'un seul document, ainsi que de publier ou encore transformer le document de scène produit. En ce qui concerne l'agrégation, le document produit est généralement statique et les aspects de formatage sont parfois proposés au sein de la chaîne de traitement. Cette étape d'agrégation peut avoir lieu au niveau - du client lui-même (le terminal multimédia) à l'aide de script (AJAX par exemple) ; ou - d'un serveur distant à la récupération du document (PHP, JPS par exemple) par le client. V007 B001 FR/TQD Dans ces deux derniers cas, le design et le formatage sont réalisés dans un seul traitement. Dans une troisième catégorie de système, l'agrégation se fait sur le serveur et les pages produites sont statiques bien qu'elles puissent être générées (et donc différentes) à chaque nouvelle requête d'un client (système CSS+ MODEL + DATA par exemple). Pour la génération d'une scène multimédia, il existe également une multitude de procédés et systèmes tels que les générateurs Flash et des boîtes à outils Web permettant de générer des présentations dynamiques (les pages web Gmail® par exemple). En termes de transformation, on peut citer, par exemple, les procédés basés sur le langage XSLT (eXtensible Stylesheet Language Transformations). Ce langage permet de transformer un document XML (Extensible Markup Language) vers un autre document (souvent XML lui aussi). Le document produit est alors statique et n'évolue pas dans le temps. Les procédés et systèmes connus sont imparfaits, notamment en raison de ce que: - la plupart des procédés existants ne produisent que des documents statiques (qui n'évoluent pas dans le temps). L'utilisateur est alors contraint de demander à nouveau la page s'il souhaite obtenir la page modifiée ; - la plupart des systèmes connus sont conçus pour ne traiter qu'un seul type de format. Leurs chaînes de génération sont entièrement construites autour du format de sortie. Il faut donc autant de chaînes de génération que de formats qu'on souhaite adresser. Certaines chaînes ne produisent que des formats propriétaires (Flash par exemple) ; - certaines solutions n'intègrent pas d'étape de formatage post injection des données brutes. Il faut donc formater les données avant de les injecter dans un modèle - ce qui pose des problèmes lorsqu'on ne connait pas forcement le design final du document ; - pour certaines solutions où les données brutes sont formatées au niveau de la génération du contenu multimédia (jsp, php, AJAX par V007 B001 FR/TQD exemple), le formatage se fait souvent au moment de la demande d'un document par le client. Il est alors nécessaire de refaire toute la couche de formatage dès lors qu'on modifie le design ; - les procédés existants ne sont pas spécifiquement orientés pour la diffusion broadcast ; - les procédés existants doivent être en général arrêtés lorsqu'il faut modifier les sources d'entrée de données, ou les modèles de services ou encore le « workflow » de traitement ; - les coûts de mise en oeuvre, d'évolution et de maintenance des systèmes connus sont généralement très élevés; - chaque client ne peut disposer d'une version optimale correspondante à sa configuration ; - l'acheminement d'un contenu multimédia complexe décrit à l'aide des modèles de description existants demeure toujours une tache difficile. Un objet de la présente invention est de remédier aux inconvénients des procédés et dispositifs de l'art antérieur. Un autre objet de la présente invention est de permettre une mise à disposition de contenus multimédia aussi automatique, rapide, et générique que possible. Un autre objet de la présente invention est de proposer une méthode d'abstraction pour la description d'une scène multimédia. Un autre objet de la présente invention est de proposer une méthode d'adaptation des contenus multimédia aux terminaux multimédia. Un autre objet de la présente invention est de définir un framework multimédia couvrant la chaîne de fourniture des contenus multimédia. Un autre objet de la présente invention est de proposer un modèle de description de scènes multimédia riches (pouvant être composées de texte, de graphique 2D/3D, de vidéo, d'images et d'audio). V007 B001 FR/TQD Un autre objet de l'invention est de mettre à disposition des utilisateurs des contenus multimédia dynamiques, générés d'une façon automatique sous différents formats. Un autre objet de la présente invention est de proposer un moteur de génération de contenus visuels, interactifs et dynamiques, indépendamment du format de sortie, du mode de transport, et des terminaux multimédia. Encore un autre objet de la présente invention est d'adapter le contenu multimédia à diverses contraintes liées au contexte d'utilisation (ou de consommation) du contenu multimédia. II est proposé, selon un premier aspect, un procédé d'agrégation et de mise en forme de contenus multimédia destinés à des terminaux multimédia, ce procédé comprenant : - une étape de formatage de métadonnées extraites à partir d'une pluralité de données sources structurées hétérogènes ; - une étape de remplissage, avec au moins une métadonnée formatée, d'au moins un template de scène afin de générer un document de scène; - une étape de publication du document de scène généré ; - une étape d'adaptation d'au moins une étape de la chaîne de génération du document de scène pour satisfaire au moins une contrainte. Ce procédé peut en outre comprendre une étape d'imbrication de templates de scènes. Selon un deuxième aspect, il est proposé un système d'agrégation et de mise en forme de contenus multimédia destinés à des terminaux multimédia, ce système comprenant : - un formateur agencé pour formater une pluralité de métadonnées extraites à partir d'une pluralité de données sources structurées hétérogènes ; V007 B001 FR/TQD - un gestionnaire de scènes agencé pour recenser les imbrications de templates de scène remplis par les métadonnées formatées afin de générer un document de scène ; - un module de publication chargé de relayer le document de scène généré ; - un contrôleur configuré pour rétroagir sur la chaîne de génération du document de scène pour satisfaire au moins une contrainte. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière concrète à la lecture de la description ci-après de modes de réalisation préférés, laquelle est faite en référence aux dessins annexés dans lesquels : la figure 1 illustre schématiquement une représentation fonctionnelle d'un mode de réalisation ; les figures 2 à7 illustrent schématiquement des modules fonctionnels, pris seuls ou en interaction, selon différents modes de réalisation. Sur la figure 1 est illustré un générateur 1 de documents de scène 4 à partir de données sources 21 structurées hétérogènes. Le générateur 1 vise à agréger, par exemple depuis des sites web et/ou des bases de données 2, des données sources pour fournir en temps réel des documents de scène 4 multi-formats indépendants des données sources structurées 21 hétérogènes d'entrée. Il est à noter qu'on entend, ici, par « document structuré dynamique » une représentation définissant un ensemble de noeuds connectés entre eux formant une arborescence (ou un arbre de scène). Conformément à la notion générale d'arbre, celui-ci se compose de noeuds dont chacun possède un nombre arbitraire (éventuellement zéro) d'enfants (ou noeuds feuille) et exactement un parent. Le modèle de document de scène 4, utilisé ci-après, étend la définition précédente d'arborescence en ajoutant une différentiation des noeuds en deux catégories : des noeuds de document, généralement des noeuds feuille, décrivant la structure interne statique du document (avec l'arborescence de noeuds groupant) et le contenu lui-même du document ; V007 B001 FR/TQD des noeuds de commande décrivant des commandes de mise à jour de la structure du document. Ces commandes sont insérées dans le document lui-même et leurs événements déclencheurs dépendent du langage associé au modèle (événement temporel, action utilisateur, réaction à une modification du document par exemple). Ainsi, un document structuré dynamique contient, dans une même arborescence, une description initiale de document statique et un ensemble de commandes applicables à celui-ci, attribuant de la sorte la dimension dynamique. Une modification apportée à une scène multimédia peut donc être vue comme une insertion, une suppression ou un remplacement de noeuds ou de feuilles, équivalente à une opération de mise à jour de l'arborescence. Le générateur 1 de documents de scène 4 comprend : un formateur 11 agencé pour formater des métadonnées extraites à partir des données sources structurées 21 (un document XML par exemple). Les métadonnées extraites se composent des attributs et des contenus des éléments du document 21, désignés ci-après par des clés. Le formateur 11 comprend une pluralité de modules unitaires de formatage organisés en chaîne et dont les sorties peuvent porter sur l'aspect temporel, spatial, ou interactif d'une scène ; un gestionnaire 12 de scènes pourvu d'une base de données 3 de templates 31 (c'est-à-dire de modèles) de scène et configuré pour recenser les imbrications des templates 31 de scène remplis par les clés afin d'obtenir un document de scène 4. Un template 31 de scènes est un document à structure dynamique déclarant des noeuds pour recevoir les clés 122, et des points d'ancrage 123 pour supporter l'imbrication d'autres templates 31 de scène. Le gestionnaire 12 de scènes possède, ainsi, une vision instantanée sur l'arborescence des templates 31 de scène relatifs au document structuré 21. un module 13 de publication, se trouvant à la sortie du générateur 1 de documents de scène, et chargé de relayer le document de scène 4 établi par le gestionnaire 12 de scènes ou de requérir, auprès de ce dernier, l'état instantané d'une scène. V007 B001 FR/TQD Les données injectées en entrée du générateur 1 proviennent de sources de données 2 diverses décorrélées n'ayant pas des connaissances des modèles - obtenus par imbrication des templates 31 de scène - à remplir. Ces données ne peuvent donc pas être insérées en l'état dans les modèles de documents. Pour cela, le formateur 11 est configuré pour permettre la mise en forme et l'enrichissement des données brutes en entrée avant leur insertion dans les modèles. En référence à la figure 2, le formateur 11 est, de préférence, composé d'une pluralité de formateur unitaires 111-114 connectés entre eux. Avantageusement, des formateurs unitaires 111-114 permettent d'obtenir, par combinaison, des « blocs de formatage » réalisant des fonctions complexes tout en maximisant les perspectives de réutilisation de chaque formateur unitaire 111-114 (ou chaque brique élémentaire). Le formateur 11 déclare des clés d'entrée sur lesquelles il effectue une ou plusieurs opérations élémentaires à l'aide des formateurs unitaires 111-114 afin de produire des clés de sortie. Ainsi, une ou plusieurs sorties prédictibles à partir de valeurs d'entrée correspondantes peuvent être produites par le formateur 11. Il est à noter qu'un formateur unitaire 111-114 peut ne pas avoir une clé d'entrée (respectivement, une clé de sortie). A titre d'exemple, un formateur unitaire 113 peut générer des valeurs en sortie sans nécessité de recueillir des données en entrée (par exemple un formateur unitaire donnant l'heure courante). Le formateur 11 assure également la gestion de la mise à jour des clés, que ce soit en entrée du module (données injectées dans le générateur 1 via l'interface dédiée) ou en sortie des formateurs unitaires 111-114. La prise en compte des mises à jour de clés fonctionne sur un mécanisme événementiel. La mise à jour d'une clé en n'importe quel point de la chaîne de formatage 110 entraîne une propagation des modifications de proche en proche au travers des différents formateurs unitaires 111-114 selon un algorithme assurant l'exécution du graphe de formatage en prévenant l'apparition de boucles infinies. V007 B001 FR/TQD En référence à la figure 3, les clés 122 disponibles en sortie de la chaîne de formatage 110 sont connectées aux modules 121 de scènes obtenus par imbrication de templates 31 de scène chargés au sein du gestionnaire 12 de scènes. L'imbrication des templates 31 de scène est faite à l'aide de points d'ancrage 123. La mise à jour d'une donnée en entrée de la chaîne de formatage 110 entraîne en sortie une mise à jour d'une ou plusieurs clés d'entrée du gestionnaire 12 de scènes. Ce gestionnaire 12 de scène applique alors la modification correspondante sur le module 121 de scènes et génère un événement (une commande) correspondant à la mise à jour effectuée. Le gestionnaire 12 de scènes a principalement pour rôle de recenser et gérer les liaisons entre les templates 31 de scène qui y sont chargés depuis la base de données 3. En effet, la création de documents de scène 4 riches à partir de documents simples est effectuée par imbrication de templates 31 de scène préalablement chargés dans la base de données 3. Ayant à tout instant une connaissance des liaisons entre les différents templates 31 de scène(les flèches, sur la figure 3, liant les points d'ancrage 123 d'une template 31 de scène à une autre template 31 de scène au sein du module 121 de scènes), le gestionnaire 12 de scène est en mesure d'effectuer sur demande une reconstruction de document de scène correspondant à toute sous-partie de son arborescence de scènes. Etant donné un point d'entrée (scène racine), il suffit de parcourir l'arbre de manière descendante en procédant récursivement à l'imbrication des scènes enfant sur le noeud ancre de leur parent. Dans un mode de réalisation, le gestionnaire 12 de scènes est un conteneur d'un « nuage de scènes » connectées entre elles, et dont chaque scène évolue au sein de ce conteneur indépendamment des autres, et génère des événements différentiels pour signaler sa mise à jour. Par ailleurs, la création et la suppression de liaisons entre les différentes scènes déclenchent également des évènements (correspondant à une insertion de noeud dans le cas d'une création de liaison, ou à une suppression de noeud pour une rupture). Ces évènements sont exposés en sortie du module, de ce fait d'autres modules peuvent se placer à l'écoute V007 B001 FR/TQD de ces évènements pour en faire une interprétation : c'est le cas du module 13 de publication. Par conséquent, l'interface de sortie du gestionnaire 12 de scènes peut assurer une pluralité de fonctions dont principalement: le relai des événements différentiels (commandes) et la construction (sur requête) de documents par imbrication de scènes (autrement dit, de templates 31 de scène) reliées entre elles. Le module 13 de publication se trouve en sortie de la chaîne de génération de documents de scène 4. Il a pour rôle d'effectuer l'export d'une arborescence de scène. A cette fin, le module de publication se déclare auprès du gestionnaire 12 de scènes comme étant à l'écoute d'une scène donnée, et va ainsi relayer les événements pour cette scène et toutes ses scènes enfants. Le module 13 de publication peut, en outre, à tout moment demander au gestionnaire de scènes 12 de lui fournir l'état courant de cette scène, il obtient alors un document agrégé à partir de la scène racine déclarée. Selon le mode d'utilisation de ces deux fonctionnalités fournies par le gestionnaire 12 de scènes, il se dessine trois catégories distinctes de publication: une publication statique : le module 13 de publication n'interprète pas les événements émis par le gestionnaire 12 de scènes. Il récupère le document agrégé (périodiquement ou non), ensuite l'exporte dans un format adéquat ; une publication dynamique : le module 13 de publication effectue un relai des événements vers une application tierce, effectuant éventuellement une transformation préalable de ces événements pour satisfaire des contraintes de langage cible. Le module 13 de publication ne se préoccupe pas de l'état global de la scène ; une publication mixte : usage simultané des deux modes de fonctionnement décrits précédemment. Le module 13 de publication permet, en effet, de récupérer l'état courant de la scène pour interpréter/transformer les événements qu'il reçoit. Il est à noter que l'ensemble des modules du générateur 1 de documents de scène 4 (c.-à-d., le formateur 11, le gestionnaire 12 de scènes, et le V007 B001 FR/TQD n module 13 de publication) sont contrôlables via des interfaces de pilotage 14-16. Ces interfaces de pilotage 14-16 donnent la possibilité à un ou plusieurs opérateur(s) extérieur(s) (humains ou non) de configurer en temps réel l'ensemble de la chaîne de génération. En effet, l'interface de contrôle 14 permet: - de configurer le formateur 11: création/suppression et la mise en liaison de formateurs unitaires 111-114, pilotage des formateurs unitaires 111-114 (si ces derniers en offrent la possibilité), gestion du graphe de formateurs (liaisons entre les formateurs unitaires 111- 114). Ainsi il est possible, par simple jeu de construction d'une chaîne de formatage par association de formateur unitaires 111-114, d'obtenir en sortie du formateur 11 une collection de clés 122 (c.à.d. des métadonnées formatées) mises en forme destinées à être insérées dans les modules 121 de scènes, comprenant des templates 31 de scène et prises en charge par le gestionnaire 12 de scènes; - de configurer le gestionnaire de scènes 12: connexion des clés 122 des modules 121 de scènes aux clés de sortie du formateur 11 (c.à.d. les métadonnées formatées par le formateur 11), création/suppression de connexions entre les différents modèles de scènes comprises dans le gestionnaire de scènes 12 (faire/défaire des imbrications des templates 31 de scène à l'aide du gestionnaire 12 de scènes. Le gestionnaire 12 de scènes permet ainsi, en tant que conteneur de nuage de scènes interconnectées, d'effectuer, sur demande depuis l'interface de contrôle 14, la reconstruction de la totalité ou d'une partie d'une arborescence de scènes); - de configurer le module 13 de publication en fonction de la fonction remplie par ce module : paramétrer les mécanismes de publication des données agrégées. Par ailleurs, l'interface d'injection 16 de templates 31 de scène représente le point d'entrée des templates 31 de scène dans le gestionnaire 12 de scènes. Dans un mode de réalisation, un template 31 de scène comprend un document XML déclarant un ensemble de clés 122 et d'ancres 123. Le V007 B001 FR/TQD générateur 1 est en mesure d'extraire ces méta-informations du template 31 de scène grâce à l'utilisation d'un espace de noms réservé à cet usage. L'interface d'injection 15 de données permet d'alimenter le formateur 11 avec des données structurées 21 hétérogènes (un document XML par exemple). Les données destinées à remplir les modèles de documents sont intégrées dans le générateur 1 sous forme de flux de données XML. Lors de l'injection d'un flux XML dans la chaîne, une collection de clés est générée en suivant une nomenclature fixe : l'élément racine du document est désigné par son nom (nom de la balise XML) le kième élément fils portant le même nom nomElement est désigné par nomElement[k-1] l'attribut nomAttribut d'un élément est désigné par #nomAttribut le contenu textuel d'un élément n'est pas désigné par un nom particulier, mais, s'il n'y pas de nom d'attribut spécifié, il peut être désigné implicitement ; les noms de clés peuvent être générées récursivement en séparant les différentes composantes par un caractère spécial tel que le caractère «.» (point). Les interfaces de pilotage 14-16 réalisent deux fonctions distinctes : les interfaces d'injection 15-16 permettent l'insertion dans le générateur des modèles de documents (interface d'injection 16 de templates 31 de scène) et des données de remplissage de ces modèles (interface d'injection 15 des données associées) ; l'interface de contrôle 14 offre quant à elle la possibilité de commander les différents modules du générateur 1 (formatage, gestion de scènes, publication). Le générateur 1, lors de l'injection d'un template 31 de scène (ou un modèle 31 de scène), parcourt le document à la recherche de ces attributs spécifiques et génère les clés et ancres correspondantes qui sont affectées au module 121 de scènes correspondant. Le générateur 1 permet ainsi de créer un module 121 de scènes pour le(s) template(s) 31 (ou le(s) modèle(e) 31) en exposant ses ancres et clés. V007 B001 FR/TQD Si un document injecté dans la chaîne de génération possède des commandes internes, alors le modèle 31 inséré dans le générateur 1 comprend au moins une scène temporelle : le document est décomposé en commandes ordonnées temporellement et qui s'exécutent en interne du module 121 de scènes. Le générateur 1 génère automatiquement une clé 122 pour chaque élément/attribut/texte du document XML 21 injecté. Ainsi, ayant connaissance de cette nomenclature, l'ensemble des formateurs unitaires 111-114 de la chaîne de formatage 110 peuvent se connecter à toute clé 122 d'un flux XML d'entrée. Par ailleurs, le générateur 1 reste connecté à ce flux de données et détecte tout changement de valeur d'une ou plusieurs valeurs. Le cas échéant, il propage la mise à jour dans l'ensemble de la chaîne (exécution du graphe de formatage 110, mise à jour des modules 121 de scènes, génération d'événements vers le module 13 de publication). Le module 13 de publication permet de produire un contenu multimédia final tout en satisfaisant au moins deux types de contraintes : des contraintes imposées par la configuration des étapes/modules de la chaîne de génération de documents de scène 4 (via les interfaces de contrôle 14 et d'injection 15-16 des modèles et données associées), généralement liées au format de données et à l'architecture du service ; des contraintes associées au format de sortie de la chaîne de génération (c.à.d. du générateur 1) de documents de scène 4 telles que des contraintes de débit ou de langage par exemple. Pour cela, une configuration fine des différents modules du générateur 1 en connaissance des caractéristiques du format de sortie est adoptée. En effet, les différents composants et contraintes du système peuvent fortement varier au cours du temps les données sources injectées dans la brique de formatage peuvent varier en nombre et en caractéristiques (poids, qualité par exemple) ; V007 B001 FR/TQD l'ancrage ou la suppression d'une scène du service global peuvent modifier le « poids » des données à publier ; la configuration de publication peut changer, notamment, le débit alloué au transport du service. D'où l'intérêt d'une configuration adaptable du générateur 1. Une configuration optimale à un instant donné peut s'avérer inadéquate suite aux modifications diverses citées ci-dessus. Afin de préserver l'optimalité du générateur 1, le module 13 de publication est chargé de contrôler l'asservissement de la chaine de génération en appliquant une nouvelle configuration à chaque modification atomique qu'il détecte. Le module 13 de publication permet d'effectuer une « rétroaction » sur l'ensemble des modules du générateur 1. En référence à la figure 4, le module 13 de publication produit donc d'une part un flux de données 18 de service multimédia, et d'autre part un flux de contrôle 17 à destination des différents modules de génération (dont le module de publication lui-même). Ainsi l'état courant du module 13 de publication est réinjecté sous forme de données de configuration des divers modules 11-13. Cet asservissement du générateur 1 aux contraintes de sortie ajoute au système une capacité d'optimisation et d'adaptation automatique en temps réel aux variations de ces contraintes. Avantageusement, les informations retournées par le module 13 de publication aident les différents modules du générateur 1 à décider de la forme et de la nature optimale des adaptations à ajouter aux traitements en cours. A cet effet, il est introduit, comme indiqué sur la figure 5, dans le formateur 12 une pluralité de paramètres de contrôle parmi les données de rétroaction 17 rebouclées depuis la sortie du module 13 de publication. Ainsi, le module de formatage 11 se retrouve asservi au flux de contrôle produit en sortie du générateur 1 et réalise donc une adaptation en temps réel des données de service sous les contraintes imposées par le module 13 de publication. V007 B001 FR/TQD Dans un mode de réalisation, l'adaptation est faite par sélection sous contrainte co, ..., cm. Ce mode de réalisation se base sur le fait de disposer de plusieurs données do, ..., dN différentes (en format, type, taille, qualité, par exemple) pouvant être substituées les unes aux autres au sein du service global. L'adaptation est réalisée par sélection d'une de ces données en fonction de paramètre(s) de contrôle permettant la prise de décision. Dans un autre mode de réalisation, le formateur 11, prenant en entrée un ensemble de données alternatives ainsi qu'une donnée de contrôle, comprend une fonction de sélection permettant la prise de décision sur la donnée à activer en sortie du formateur 11. L'implémentation de la fonction de sélection peut se faire selon plusieurs modèles différents : décision externe : la prise de décision ne s'effectue pas au sein du formateur 11. Ce dernier offre simplement la possibilité de sélectionner par aiguillage direct l'entrée à rediriger vers la sortie du formateur 11; décision interne : le formateur 11 prend en entrée un ensemble de contraintes co, ..., cm et implémente en interne une fonction F(co, ..., cm, do, ..., dN) de décision réalisant la sélection de la donnée à produire en sortie. La figure 5 illustre un formateur avec fonction de décision F(co, ..., cm, do, dN) capable de sélectionner, par exemple, une image parmi un ensemble d'images de tailles, formats et poids (do, ..., dN) différents. Dans un autre mode de réalisation, l'adaptation est réalisée par une transformation sous contraintes. Ce mode de réalisation propose d'effectuer une adaptation sur une donnée unique en agissant par transformation de celle-ci pour satisfaire un ensemble de contraintes (co, ..., cm). A titre d'exemple, un formateur, prenant en entrée une donnée image haute résolution permet de produire en sa sortie une image dégradée répondant au mieux à des contraintes de débit, de format ou d'espace disponible au niveau du service. Par ailleurs, l'adaptation peut être obtenue par rétroaction sur le gestionnaire 12 de scènes. En effet, dans une architecture de service modulaire offrant plusieurs alternatives de format de service pouvant être V007 B001 FR/TQD substituées les unes aux autres pour satisfaire un ensemble de contraintes de sortie, un ou plusieurs modules 121 de scènes (ou conteneurs 121 de scènes) peuvent être reliés à un certain nombre de sous-scènes alternatives, comme indiqué dans la figure 6. Les données de contrôle 17 (obtenues par rétroaction) agissent sous forme de commandes de pilotage du gestionnaire 12 de scènes réalisant la création et la rupture de liaisons entre le conteneur 121 et la scène i choisie pour réaliser l'adaptation. Chaque modification de contraintes en sorties du module 13 de publication entraîne une rétroaction sur le gestionnaire 12 de scènes définissant une nouvelle configuration de l'architecture de service répondant au mieux à ces contraintes. La figure 7 illustre un exemple de scénario d'adaptation de service sous contrainte de débit : trois scènes alternatives y sont définies, chacune étant calibrée pour satisfaire une plage de débit particulière : une scène contenant une vidéo et nécessitant donc un débit important. une scène comportant une image et un texte descriptif adaptée à un débit de transmission « moyen ». un texte descriptif seul adapté pour un faible débit de transmission. La figure 7 illustre un cas où la variation du débit disponible pour la transmission des données entraîne un changement du contenu du service (vidéo, image+texte ou texte seul). Les données de contrôle 17 générées par le module 13 de publication peuvent également être utilisées par celui-ci pour adapter sa stratégie de publication aux variations de contraintes. Nous prenons ici l'exemple d'un système de génération de flux broadcast (de type MPEG-2 TS). Le module 13 de publication comprend: un multiplexeur fonctionnant sur une architecture de diffusion pouvant être vue comme un ensemble de flux transportant des données sous forme de paquets. Le multiplexeur a pour rôle de créer un flux de transport unique par sélection de paquets sur l'ensemble de ses flux d'entrée selon un algorithme d'aiguillage. Chaque flux d'entrée V007 B001 FR/TQD possède sa configuration propre (débit cible, période de répétition des données par exemple) qui sont autant de contraintes à résoudre pour l'algorithme d'aiguillage dans le but de produire un flux multiplexé répondant aux mieux à l'ensemble de ces contraintes ; un encodeur : chaque flux d'entrée du multiplexeur dispose d'un encodeur pour permettre le transport des données sur le flux multiplexé. Les données peuvent être de types différents (audio, vidéo, dessin vectoriel par exemple), ce qui explique que chaque flux à multiplexer possède son propre encodeur, avec une configuration propre (notamment le débit cible). L'algorithme d'aiguillage du multiplexeur prend en compte ces contraintes lors de la production du flux multiplexé. un organiseur : les données à publier, issues du gestionnaire 12 de scènes, sont injectées dans une brique appelée « organiseur ». Son rôle est de ventiler le service multimédia sur les différents flux de l'architecture de diffusion. Il doit pour cela effectuer une projection du service produit par le gestionnaire de scène, ainsi que des événements de mise à jour du service, sur les différents flux d'entrée du multiplexeur ; un contrôleur : les trois briques précédemment décrites forment une chaîne de traitement séquentielle « branchée » en sortie du gestionnaire 12 de scènes. En règle générale dans le cas d'une chaîne de diffusion, le flux produit par le multiplexeur est soumis à des contraintes de débit strictes imposées soit par la norme de diffusion ou bien par l'entité chargée de la diffusion du flux de transport. Ces contraintes sont donc imposées au multiplexeur qui se trouve être le dernier maillon de la chaîne de génération. Le contrôleur se tient informé à tout instant de l'état du Multiplexeur et peut effectuer une rétroaction sur l'ensemble de la chaîne de génération : o le formateur 11/ le gestionnaire 12 de scènes: le contrôleur peut rétroagir sur ces modules pour adapter au mieux le service, que ce soit dans sa structure (rétroaction sur le gestionnaire 12 de scène) ou dans son contenu (rétroaction sur le formateur 11 de données associées), aux contraintes de diffusion. Ceci peut par exemple permettre, en cas d'une diminution du débit disponible, d'alléger le poids de données V007 B001 FR/TQD images ou bien encore de proposer des scènes alternatives moins « gourmandes » en débit ; o l'organiseur : une rétroaction sur l'organiseur offre la possibilité de modifier en temps réel la stratégie de projection des données de service sur les flux de diffusion. Par exemple, en cas d'un débit trop important en sortie, l'organiseur peut effectuer du partage de flux en redirigeant plusieurs sorties sur le même flux de diffusion (par exemple en groupant les données de scène et de mise à jour sur le même flux de diffusion) ; o les encodeurs : si les différents encodeurs (audio, vidéo, scène par exemple) possèdent des degrés de liberté sur la qualité de leur encodage, il est possible d'effectuer une rétroaction sur ces briques de traitement pour modifier par exemple les débits d'encodage de flux audio ou vidéo en réponse à des variations de débit disponible en sortie de la chaîne de génération; o le multiplexeur : il est possible d'effectuer un retour direct sur le module de multiplexage lui-même. En effet ce dernier peut adapter sa stratégie d'aiguillage pour répartir au mieux le débit disponible sur l'ensemble des flux à multiplexer. Il en résulte qu'avantageusement le contenu média obtenu est adapté aux contraintes du contexte de consommation, telles que les capacités du terminal, les préférences de l'utilisateur, les capacités du réseau. Le procédé qui vient d'être décrit présente un certain nombre d'avantages. 25 Il permet en effet de favoriser le développement du marché du multimédia sur les réseaux bas-débits comme les réseaux sans-fil et par des terminaux au ressources réduites comme les téléphones mobiles et les Smartphones. Il est à noter que le terme « module » recouvre ici tout boîtier physique intégrant un processeur programmé pour assurer une ou plusieurs fonctions 30 prédéterminées, ou toute application logicielle (programme ou sous-programme, plugin) implémentée sur un processeur, indépendamment ou en combinaison avec d'autres applications logicielles. V007 B001 FR/TQD 10 15 20 REVENDICATIONS1. Procédé d'agrégation et de mise en forme de contenus multimédia destinés à des terminaux multimédia, ce procédé comprenant - une étape de formatage de métadonnées extraites à partir d'une pluralité de données sources (21) structurées hétérogènes ; - une étape de remplissage, avec au moins une métadonnée formatée, d'au moins un template (31) de scène afin de générer un document de scène (4); - une étape de publication du document de scène (4) généré ; - une étape d'adaptation d'au moins une étape de la chaîne de génération du document de scène (4) pour satisfaire au moins une contrainte. 2. Procédé selon la revendication 1 caractérisé en ce qu'il comprend en outre une étape d'imbrication de templates (31) de scènes. 3. Procédé selon l'une quelconques des revendications 1 ou 2, caractérisé en ce que les données sources structurées (21) est un document XML. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le template (31) de scène est un document à structure dynamique déclarant des noeuds pour recevoir des métadonnées formatées, et des points d'ancrage (123) pour supporter l'imbrication d'autres templates (31) de scène. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la contrainte est une contrainte associée au format de sortie de la chaîne de génération du document de scène (4). 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la contrainte est une contrainte imposée par la configuration d'au moins un module de la chaîne de génération du document de scène (4). V007 B001 FR/TQD 7. Système d'agrégation et de mise en forme de contenus multimédia destinés à des terminaux multimédia, ce système comprenant - un formateur (11) agencé pour formater une pluralité de métadonnées extraites à partir d'une pluralité de données sources (21) structurées hétérogènes ; - un gestionnaire (12) de scènes agencé pour recenser les imbrications de templates (31) de scène remplis par les métadonnées formatées afin de générer un document de scène (4) ; - un module (13) de publication chargé de relayer le document de scène (4) généré ; - un contrôleur configuré pour rétroagir sur la chaîne de génération du document de scène (4) pour satisfaire au moins une contrainte. 8. Système selon la revendication précédente, caractérisé en ce qu'il comprend en outre une base de données (3) de templates (31) de scène. 9. Système selon l'une quelconque des revendications 7 ou 8, caractérisé en ce que le module (13) de publication est agencé pour requérir, auprès du gestionnaire (12) de scène, l'état instantanée d'un document de scène (4). 10. Système selon l'une quelconque des revendications 7 à 9, caractérisé en ce que le formateur (11) comprend une pluralité de formateurs unitaires (111-114). 11. Système selon l'une quelconque des revendications 7 à 10, caractérisé en ce que le template (31) de scène est un document à structure dynamique déclarant des noeuds pour recevoir des métadonnées formatées, et des points d'ancrage (123) pour supporter l'imbrication d'autres templates (31) de scène. 12. Système selon l'une quelconque des revendications 7 à 11 , caractérisé en ce qu'il comprend en outre - une interface de contrôle (14) agencé pour configurer le formateur (11), le gestionnaire (12) de scènes et le module (13) de publication ; V007 B001 FR/TQD - une interface d'injection (16) de templates (31) de scène permettant l'insertion de templates (31) de scène dans le gestionnaire (12) de scènes ; - une interface d'injection (15) de données permettant d'alimenter le formateur (11) avec des données structurées (21) hétérogènes. 13. Système selon l'une quelconque des revendications 7 à 12, caractérisé en ce que la contrainte est une contrainte imposée par la configuration d'au moins un module de la chaîne de génération du document de scène (4). 14. Système selon l'une quelconque des revendications 7 à 13, caractérisé en ce que la contrainte est une contrainte associée au format de sortie de la chaîne de génération du document de scène (4). 15. Produit programme d'ordinateur implémenté sur un support mémoire, susceptible d'être mis en oeuvre au sein d'une unité de traitement informatique et comprenant des instructions pour la mise en oeuvre d'un procédé selon l'une des revendications 1 à 6. V007 B001 FR/TQD