FR 2746532 A1 19970926 FR 9603911 A 19960325 Système de développement et d'exécution d'applications multimédias, procédés de développement et de mise à jour de données correspondants. Le domaine de l'invention est celui des applications multimédias offrant à un utilisateur l'accès, de façon interactive, à des données de différentes natures (textes, images et sons). On connaît différents types d'applications multimédias, tels que les titres CD-ROM (disque optique compact), les applications tournant sur des bornes interactives ou encore les applications tournant sur un serveur d'un réseau (réseau Internet par exemple). Plus précisément, l'invention concerne un système de développement et d'exécution d'applications multimédias, ainsi que des procédés de développement et de mise à jour de données correspondants. Jusqu'à présent, les sociétés de production de CD-ROM utilisent un produit multimédia et développent entièrement les applications multimédias finales avec ce produit. La production d'un CD-ROM comprend deux phases. Dans une première phase, une application multimédia est développée, qui doit mettre en oeuvre notamment des fonctions d'animation graphique d'objets, de gestion de données et de navigation entre objets. Dans une seconde phase, une application multimédia finale est générée à partir de l'application multimédia préalablement développée. Cette application multimédia finale (ou runtime), qui inclut une version exécutable du produit multimédia sous lequel elle a été développée, est stockée sur un support physique (CD ROM, borne interactive), de façon que ladite application multimédia finale s'exécute de façon autonome ("off-line"). Actuellement, il existe un produit standard sur le marché, à savoir le produit Director (marque déposée). D'une très grande qualité d'animation graphique et pouvant incorporer tout type d'images, ce produit permet la création d'applications multimédias interactives très sophistiquées. Cependant, avec ce produit, lors du développement d'une application multimédia, la mise au point de la navigation, et surtout la manipulation des données qui sont utilisées par cette application multimédia, sont extrêmement fastidieuses. Le problème devient pratiquement insoluble lorsque, dans une application multimédia, il s'agit de changer une partie des données utilisées et de prendre en compte, au niveau de la navigation, toutes les conséquences de ce changement. En effet, toute la programmation d'une application mutlimédia se fait avec le langage de programmation propre à ce produit, à savoir le langage Lingo (marque déposée). Or, le langage Lingo est très performant pour ce qui est de la programmation des fonctions graphiques, mais en revanche il est peu adapté à la programmation des accès aux données ni à celle de la logique de navigation. Ainsi, tous les accès aux données et leur gestion sont programmés en Lingo à l'intérieur du titre. Par conséquent, toute modification des données nécessite une modification du programme réalisé en Lingo. La modification d'un titre est donc très longue et difficile à réaliser. Par ailleurs, le déplacement d'un objet vers un autre objet lors d'une action de l'utilisateur, doit être spécifié et décrit pour chaque objet. Ces liens, appelés liens Hyper Texte, sont donc à programmer en Lingo. L'ensemble de ces liens constitue la logique de navigation associée au titre (c'est-à-dire à l'application multimédia). Enfin, la mise au point de l'application multimédia, qui comprend la suppression de toutes les erreurs de programmation, est longue et fastidieuse. Toute modification est en outre susceptible de bouleverser et remettre en cause de nombreux objets, ainsi que toutes les programmations qui leur sont liées. En d'autres termes, avec le produit Director, il est très difficile de programmer les fonctions de gestion de données et de navigation propres à chaque application multimédia. On connaît également d'autres produits multimédias de développement de CD ROM, tels que Hypercard (marque déposée) ou Apple Media Tool (marque déposée). Mais d'une façon générale, aucun de ces produits ne permet de développer très simplement l'ensemble des fonctions d'animation graphique d'objets, de gestion de données et de navigation entre objets que chaque application multimédia doit mettre en oeuvre. 11 est également important de noter qu'actuellement, lorsque l'on désire mettre à jour les données utilisées dans une application mutlimédia, il faut réécrire en grande partie le programme de cette application puisque les données sont internes à ce programme. Avec une application multimédia utilisant des données qui n'évoluent pas ou peu dans le temps, cette réécriture importante de programme intervient rarement et n'est donc pas très gênante. ll s'agit par exemple d'une application multimédia concernant un musée (par exemple, le CD-ROM du Louvre). En revanche, lorsque les données utilisées par une application multimédia changent régulièrement, les fréquentes réécritures importantes de programme deviennent très coûteuses. I1 s'agit par exemple d'un catalogue commercial devant être mis à jour à période fixe. Pour cette raison, peu d'applications multimédias de ce type sont développées actuellement alors que les demandeurs sont potentiellement très nombreux. On pense notamment à toutes les entreprises, tous secteurs d'activités confondus, qui désirent utiliser des applications multimédias comme moyens de communication ou de commercialisation de l'information ou de leurs produits et services. L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention est de fournir un système qui permette de simplifier le développement et la mise au point des applications multimédias, notamment en facilitant la programmation de l'accès aux données et en supprimant la programmation spécifique des liens HyperTextes dans les programmes de ces applications multimédias. L'invention a également pour objectif un tel système qui permette de mettre àjour simplement les données utilisées par une application multimédia finale (runtime) sans nécessiter aucune modification dans celle-ci, c'est-à-dire sans nouvelle programmation de l'application. Un autre objectif de l'invention est de fournir un tel système qui permette de réduire sensiblement le temps de réalisation des applications multimédias. Un objectif complémentaire de l'invention est de fournir un tel système qui permette de diminuer les coûts de réalisation et de suivi des applications multimédias. Encore un autre objectif de l'invention est de fournir un tel système qui permette à une pluralité d'applications multimédias (Internet, bornes interactives, systèmes de recherche et de banque de données, etc.) de travailler avec des données parfaitement mises à jour en permanence. Un autre objectif de l'invention est de fournir un tel système pouvant être utilisé avec tous les produits multimédias du marché, et permettant de créer de nouveaux types d'applications multimédias, exploitables aussi bien sur des supports numériques (CD ROM, bornes interactives) qu'à travers le réseau Internet (WEB). Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un système de développement et/ou d'exécution d'applications multimédias mettant chacune en oeuvre notamment des fonctions d'animation graphique d'objets, une politique de gestion de données et une logique de navigation entre objets, ledit système étant caractérisé en ce qu'il comprend: - un serveur principal incluant un moteur relationnel associé à une base de données relationnelle contenant des données à intégrer dans des applications multimédias, ledit moteur relationnel comprenant notamment: * un gestionnaire de relations, constituant le noyau de ladite base de données relationnelle et comprenant au moins un ensemble de relations, chaque ensemble de relations définissant une politique de gestion de données et une logique de navigation entre objets propres à chaque application multimédia ; et * un gestionnaire de saisie interactive, permettant la création et/ou la modification de chaque ensemble de relations; - au moins un poste de gestion, relié audit serveur principal via des interfaces de communication et supportant un premier produit multimédia (Hypercard) auquel sont adjointes les fonctionnalités dudit moteur relationnel sous forme de fonctions externes pouvant être appelées au moyen d'une commande spécifique (XCMD) du langage de programmation (Hypertalk) propre audit premier produit multimédia, ledit premier produit multimédia utilisant lesdites fonctions externes pour créer et/ou modifier chaque ensemble de relations; - au moins un poste de développement, relié audit serveur via des interfaces de communication et supportant un second produit multimédia (Hypercard, Director, Apple Media Tool) auquel sont adjointes les fonctionnalités dudit moteur relationnel sous forme de fonctions externes pouvant être appelées au moyen d'une commande spécifique (XCMD, Xobjet, Librairies) du langage de programmation (Hypertalk, Lingo, K) propre audit second produit multimédia, ledit second produit multimédia utilisant lesdites fonctions externes pour que l'application multimédia qu'il permet de développer mette en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur ledit serveur principal. Le principe général de l'invention consiste donc à déporter dans un serveur principal les fonctions de gestion de données et de navigation de chaque application multimédia. Ce sont les fonctions externes ajoutées au produit multimédia du poste de gestion qui permettent à celui-ci d'être utilisé pour administrer le serveur principal, c'est-à-dire pour définir pour chaque application multimédia une politique de gestion de données et une logique de navigation distinctes. Ce sont ces mêmes fonctions externes ajoutées au produit multimédia du poste de développement qui permettent à celui-ci d'être utilisé pour associer à une application multimédia en cours de développement une politique de gestion de données et une logique de navigation préalablement définies, qui sont déportées sur le serveur principal, et qui lui sont propres. En d'autres termes, pour chaque application multimédia développée dans le poste de développement, tous les accès aux données et leur gestion sont programmés, via une commande spécifique du langage de programmation propre au produit multimédia utilisé (par exemple Lingo pour le produit Director), en utilisant les fonctions externes. La politique de gestion de données et la logique de navigation de cette application multimédia ne sont pas directement écrites dans le programme mais sont déportées sur le serveur principal et accessibles grâce aux fonctions externes. Pour ce qui est de la gestion des données et la logique de navigation, le programme de l'application multimédia contient donc uniquement des commandes d'appel des fonctions externes. La programmation d'une application multimédia est donc considérablemnt simplifiée. Tous les liens entre les objets sont implicites car ils sont décrits dans les relations existantes dans la base de données et définies dans le moteur relationnel du serveur principal. I1 n'y a donc pas de programmation spécifique à faire, ni de liens HyperTexte à gérer. De plus, il n'y a pas non plus de modification de programme à effectuer lorsqu'il s'agit de mise àjour de données. Les applications multimédias peuvent se développer beaucoup plus rapidement du fait que la gestion des données et la navigation sont traitées en dehors des outils de présentation, ces derniers étant utilisés uniquement pour l'aspect graphique des applications multimédias. Compte-tenu de ce qui précède, la mise au point d'une application multimédia (et notamment dun titre CD-ROM) est beaucoup plus simple que précédemment, en ce qui concerne la gestion de données, et quasiment inexistante pour la navigation. 1l est à noter que le serveur principal peut travailler avec une pluralité de postes de développement et donc permettre le développement simultané de plusieurs applications multimédias. En effet, il gère séparément une pluralité d'ensembles de relations associés chacun à une application multimédia distincte développée sur un des postes de développement. De façon avantageuse, ledit système comprend également au moins un poste de consultation, relié audit serveur principal via des interfaces de communication et supportant une application multimédia finale (ou runtime) incluant une version exécutable du second produit multimédia (Hypercard, Director, Apple Media Tool) sous lequel elle a été développée et auquel sont adjointes les fonctionnalités dudit moteur relationnel sous forme de fonctions externes, ladite application multimédia finale utilisant lesdites fonctions externes pour mettre en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur ledit serveur principal. De cette façon, le serveur principal est utilisé lors du développement des applications multimédias, mais également lors de leur exécution. Ces applications multimédias finales (ou runtimes) utilisent en ligne (on-line), c'est-à-dire à distance et en temps réel, les fonctions de gestion de données et de navigation qui leur sont associées sur le serveur principal. Avantageusement, ledit système comprend également au moins un serveur de consultation appartenant à un réseau externe (Internet), ledit serveur de consultation étant relié audit serveur principal via des interfaces de communication et supportant une application multimédia finale exécutable sous un troisième produit multimédia (Webstar) auquel sont adjointes les fonctionnalités dudit moteur relationnel sous forme de fonctions externes pouvant être appelées au moyen d'une commande spécifique (cgi), ladite application multimédia finale utilisant lesdites fonctions externes pour mettre en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur ledit serveur principal. Ainsi, un ou plusieurs serveurs de consultation, par exemple du réseau Internet, utilisent en ligne (on-line) le serveur principal, de façon à accéder aux fonctions de gestion de données et de navigation qui leur sont associées sur ce serveur principal. Dans ce cas d'un serveur de consultation en ligne, on entend par application multimédia finale exécutable notamment une présentation écrite avec un éditeur de pages HTML. Préférentiellement, ledit poste de gestion et/ou ledit poste de développement et/ou ledit poste de consultation et/ou ledit serveur de consultation sont reliés audit serveur par l'intermédiaire d'un réseau. Selon une variante avantageuse, ledit serveur principal, ledit poste de gestion, ledit poste de développement, ledit poste de consultation et ledit serveur de consultation sont regroupés sur une même station de travail. On est dans ce cas en présence de communications inter-applications. Dans un mode de réalisation avantageux de l'invention, ledit moteur relationnel comprend également au moins un des gestionnaires appartenant au groupe comprenant: - un gestionnaire de schéma, permettant de décrire les liens qui existent entre les relations d'une application multimédia; - un gestionnaire de listes, permettant la présentation et/ou la visualisation d'éléments, en travaillant sur les liens récupérés depuis ledit serveur principal en mémoire locale d'un desdits poste de gestion, développement ou consultation ou dudit serveur de consultation; - un gestionnaire d'utilitaire système, permettant de faire tout type de manipulation de fichiers dans le serveur principal et et traiter tout type de chaînes de caractères dans les fichiers; - un gestionnaire de statistiques, permettant de mettre en oeuvre un ensemble de fonctionnalités d'exploitation et/ou de statistiques; - un gestionnaire d'impression, permettant de prendre en charge les impressions, de façon indépendante des applications multimédias. De façon préférentielle, lesdites fonctions externes comprennent des moyens de construction et d'envoi de requêtes audit serveur principal, ainsi que des moyens de récupération de réponses dudit serveur principal auxdites requêtes. Avantageusement, les données de ladite base de données sont stockées sur le serveur principal ou réparties entre le serveur principal et le poste de gestion et/ou poste de développement et/ou le poste de consultation et/ou le serveur de consultation. Dans une variante de réalisation préférentielle du système de l'invention, le système ne comprend pas de serveur mais une station de travail unique incluant: - au moins une application de gestion, qui constitue l'équivalent du poste de gestion du premier mode de réalisation, cette application de gestion incluant ledit moteur relationnel; - au moins une application de développement, qui constitue l'équivalent du poste de développement du premier mode de réalisation. Dans ce cas, toutes les applications étant regroupées sur une même station de travail, elles se partagent directement un même espace mémoire dans lequel sont stockées les politiques de gestion de données et les logiques de navigation du moteur relationnel. Le serveur utilisé dans le premier mode de réalisation n'est donc pas nécessaire ici puisqu'il est utilisé pour déporter le moteur relationnel, avec les politiques de gestion de données et les logiques de navigation qu'il contient, afin de le rendre accessible par les postes de développement et de consultation. I1 est à noter qu'avec cette variante, l'absence de serveur empêche la multi utilisation avec plusieurs applications multimédias se partageant une même base de données, ainsi que la simultanéité lors la mise à jour des données. Avantageusement, dans cette variante, la station de travail unique peut inclure également une application de consultation, qui constitue l'équivalent du poste de gestion du premier mode de réalisation. L'invention concerne également un procédé de développement d'une application multimédia dans un système tel que présenté ci-dessus, ledit procédé étant caractérisé en ce qu'il comprend les étapes suivantes: - on utilise le poste de gestion pour définir une politique de gestion de données et une logique de navigation entre objets propres à une application multimédia, par création et/ou modification, dans le gestionnaire de relations du moteur relationnel du serveur principal, d'un ensemble de relations propre à une application multimédia; - on utilise le poste de développement pour développer une application multimédia en y incorporant, via l'appel des fonctions externes au moyen de ladite commande spécifique, la politique de gestion de données et la logique de navigation entre objets propres définies pour ladite application multimédia lors de l'étape précédente. Avantageusement, ledit procédé de développement comprend également une étape de génération, à partir de l'application multimédia préalablement développée, d'une application multimédia finale destinée à être supportée par un poste de consultation relié audit serveur principal, de façon que ladite application multimédia finale communique en ligne ("on-line") avec ledit serveur principal lors de son exécution. Selon une variante avantageuse, ledit procédé de développement comprend également une étape de génération, à partir de l'application multimédia préalablement développée, d'une application multimédia finale destinée à être stockée sur un support physique (CD ROM, borne interactive) stockant également le contenu à un instant donné dudit serveur principal, de façon que ladite application multimédia finale s'exécute de façon autonome ("off-line"). L'invention concerne aussi un procédé de mise à jour de données d'applications multimédias développées et/ou exécutées dans un système tel que décrit ci-dessus, ledit procédé étant caractérisé en ce qu'il comprend une étape de mise à jour des données de ladite base de données. Cette mise à jour de données est indépendante des programmes des applications multimédias finales. Par conséquents, ceux-ci n'ont pas à être modifiés lorsque les données qu'ils utilisent sont mises àjour. Dans le cas d'une application multimédia finale sur CD-ROM, il suffit de stocker sur le nouveau CD-ROM le contenu du serveur principal à un nouvel instant donné, l'application multimédia finale stockée restant quant à elle inchangée. Dans le cas d'applications multimédias finales qui sont exécutées en ligne (online), on leur permet de disposer en temps réel de ces données mises à jour. 1l est à noter que la simultanéité des réponses du serveur principal aux postes de développement, aux postes de consultation et aux serveurs de consultation, ainsi que la mise à jour en temps réel des données assurent une parfaite cohérence au système. En effet, cela permet aux différentes applications multimédias (celles développées et celles exécutées) de travailler avec des données parfaitement àjour en permanence. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels: - la figure 1 présente un schéma synoptique d'un mode de réalisation particulier du système de l'invention; la figure 2 reprend en le détaillant le schéma synoptique de la figure 1 ; - la figure 3 présente un schéma constitutif d'un mode de réalisation particulier du moteur relationnel apparaissant sur le schéma de la figure 2; - la figure 4 présente un organigramme simplifié d'un mode de réalisation particulier du procédé selon l'invention de développement d'une application multimédia; - la figure 5 présente un organigramme simplifié d'un mode de réalisation particulier du procédé selon l'invention de mise àjour de données ; et - la figure 6 présente un organigramme simplifié de l'exécution d'une commande du gestionnaire de relations apparaissant sur le schéma de la figure 3. L'invention concerne donc un système de développement et d'exécution d'applications multimédias. Le principe général du système de l'invention consiste à ne pas intégrer à l'intérieur du programme de chaque application multimédia la politique de gestion de données et la logique de navigation propre à cette application multimédia. Dans le mode de réalisation particulier présenté ci-dessous, en relation avec les figures 1 à 6 , les fonctions de gestion de données et de navigation sont déportées sur un serveur principal. I1 est clair cependant que l'invention n'est pas limitée à ce mode de réalisation particulier, mais concerne également le cas où ces fonctions de gestion de données et de navigation, bien qu'effectuées hors de l'application multimédia, sont néanmoins placées sur un même support physique que celle-ci. Dans ce cas, une même station de travail supporte notamment une application de gestion, une application de développement et éventuellement une application de consultation, et il n'y a donc plus de serveur. Le système de la figure 1 comprend un serveur principal 1 auquel sont reliés un poste de gestion 2, un poste de création graphique 3, deux postes de développement 4, 5, deux postes de consultation 6, 7 et un serveur de consultation 8. Le serveur principal 1 stocke les politiques de gestions de données et les logiques de navigation de différentes applications multimédias en cours de développement (sur les postes de développement 4, 5) ou en cours d'exécution (par les postes de consultation 6, 7 ou le serveur de consultation 8). Le poste de création graphique 3, qui inclut divers outils de création graphique (acqisition, retouche, dessin, capture, etc.), permet de créer de nouvelles données, et notamment des objets multimédias, destinées à être utilisées par les applications multimédias. Ces données peuvent être intégrées aux enregistrements de la base de données relationnelle du serveur principal 1, ou bien être externes à cette base de données. Dans le dernier cas, la base de données contient des pointeurs permettant d'adresser ces données externes. Le poste de gestion 2 supporte par exemple le produit multimédia Hypercard (marque déposée) et permet permet de créer ou modifier les politiques de gestion de données et les logiques de navigation propres aux différentes applications multimédias et stockées sur le serveur principal 1. Le premier poste de développement 4 supporte par exemple le produit multimédia Director (marque déposée) et permet de développer des applications multimédias programmées en langage Lingo (marque déposée). A partir des applications multimédias développées sur ce premier poste de développement 4, il est possible de générer une application multimédia finale (ou runtime) exécutable soit sur le premier poste de consultation 6, soit sur un CD-ROM 9 (ou tout autre support physique autonome). Le second poste de développement 5 supporte par exemple le produit multimédia Apple Media Tool (marque déposée) et permet de développer des applications multimédias programmées en langage K (marque déposée). A partir des applications multimédias développées sur ce second poste de développement 5, il est possible de générer une application multimédia finale exécutable sur le second poste de consultation 7. Ce second poste de consultation 7 est par exemple une télévision supportant une application multimédia de télévision interactive (pour cela cette télévisison 7 est bien sûr équipée de moyens appropriés, non représentés sur la figure 1). Le serveur de consultation 8 est par exemple un serveur du réseau Internet qui supporte le produit multimédia Webstar (marque déposée) et permet d'exécuter une application multimédia finale (dite présentation finale, dans ce cas particulier) préalablement écrite avec un éditeur de pages HTML. La figure 2 reprend en le détaillant le schéma synoptique de la figure 1. Le serveur principal 1 comprend une interface de communication 13, lui permettant de dialoguer avec les différents postes (gestion, création graphique, développement et consultation) 2 à 7 et serveurs de consultation 8. n inclut également une "application serveur" classique 1 1 ainsi qu'un moteur relationnel 12 associé à une base de données relationnelle (non représentée) contenant des données ou des pointeurs de données à intégrer dans des applications multimédias. En pratique, ces données peuvent être toutes stockées sur le serveur principal 1 ou bien réparties entre le serveur principal 1 et les postes de gestion 2, développement 4, 5, consultation 6, 7 et le serveur de consultation 8. La figure 3 présente un schéma constitutif d'un mode de réalisation particulier du moteur relationnel 12, dans lequel celui-ci comprend les sept gestionnaires suivants: - un gestionnaire de relations 31, constituant le noyau de la base de données relationnelle et comprenant au moins un ensemble de relations, chaque ensemble de relations définissant une politique de gestion de données et une logique de navigation entre objets propres à chaque application multimédia. Le modèle de données sur lequel s'appuie la base données est le modèle relationnel entités-associations distribué - un gestionnaire de saisie interactive 32, permettant la création et/ou la modification de chaque ensemble de relations; - un gestionnaire de schéma 33, permettant de décrire les liens qui existent entre les relations d'une application multimédia; - un gestionnaire de listes 34, permettant la présentation et la visualisation d'éléments, en travaillant sur les liens récupérés depuis le serveur principal 1 en mémoire locale d'un des postes de gestion 2, développement 4, 5 ou consultation 6, 7 ou du serveur de consultation 9; - un gestionnaire d'utilitaire système 35, permettant de faire tout type de manipulation de fichiers (création, élimination, modification de fichier ou de répertoires, etc.) dans le serveur principal 1 et et traiter tout type de chaînes de caractères dans les fichiers; - un gestionnaire de statistiques 36, permettant de mettre en oeuvre un ensemble de fonctionnalités d'exploitation et/ou de statistiques, sur les parcours par exemple, de façon totalement indépendantes des applications. Les sorties peuvent être soit imprimées, soit récupérables dans des fichiers ASCII par d'autres applications comme Excel (marque déposée) ; et - un gestionnaire d'impression 37, permettant de prendre en charge les impressions (diverses ou étiquettes), de façon indépendante des applications multimédias. Il est à noter que seuls les gestionnaire de relations 31 et de saisie interactive 32 travaillent en relation avec le serveur principal 1, les autres travaillant de façon autonome. Le poste de gestion 2 est relié au serveur principal 1 via une interface de communication 23. Il supporte le produit multimédia Hypercard (marque déposée) 21, auquel sont adjointes les fonctionnalités du moteur relationnel 12, sous forme de fonctions externes 22. Ces fonctions externes 22 peuvent être appelées au moyen de la commande spécifique XCMD, du langage de programmation Hypertalk (marque déposée), propre à ce produit multimédia Hypercard. Le produit multimédia Hypercard 21 utilise les fonctions externes 22 pour créer et/ou modifier chaque ensemble de relations (c'est-à-dire la politique de gestion de données et la logique de navigation de chaque application mutlimédia). Chaque poste de développement 4, 5 est relié au serveur principal 1 via une interface de communication 43, 53. I1 supporte un produit multimédia (Director et Apple Media Tool respectivement) 41, 51, auquel sont adjointes les fonctionnalités du moteur relationnel 12, sous forme de fonctions externes 42, 52. Ces fonctions externes 42, 52 peuvent être appelées au moyen d'une commande spécifique (Xobjet et Librairies respectivement) du langage de programmation (Lingo et K respectivement) propre à ce produit multimédia. Le produit multimédia 41, 51 utilise les fonctions externes 42, 52 pour que l'application multimédia qu'il permet de développer mette en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur le serveur principal 1. Chaque poste de consultation 6, 7 est relié au serveur principal 1 via une interface de communication 63, 73. I1 supporte une application multimédia finale (ou runtime) 61, 71 incluant une version exécutable du produit multimédia (Directore et Apple Media Tool respectivement) sous lequel elle a été développée. A ce runtime 61, 71 sont adjointes les fonctionnalités du moteur relationnel 12, sous forme de fonctions externes 62, 72. Par ailleurs, ce runtime 61, 71 utilise les fonctions externes 62, 72 pour mettre en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur le serveur principal 1. Le serveur de consultation 8 est relié au serveur principal 1 via une interface de communication 83. I1 supporte une application multimédia (ou présentation) finale 81 exécutable sous le produit multimédia Webstar (marque déposée). A cette application multimédia finale 81 sont adjointes les fonctionnalités du moteur relationnel 12, sous forme de fonctions externes 82. Ces fonctions externes 82 peuvent être appelées au moyen de la commande spécifique cgi. L'application multimédia finale 81 utilise les fonctions externes 82 pour mettre en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur le serveur principal 1. Les différents postes 2 et 4 à 7 et le serveur de consultation 8 sont reliés au serveur principal 1 par un réseau 10. I1 s'agit par exemple du réseau interne d'une entreprise. Par ailleurs, les fonctions externes 22, 42, 52, 62, 72, 82 de ces différents postes 2 et 4 à 7 et du serveur de consultation 8 comprennent des moyens (non représentés) de construction et d'envoi de requêtes au serveur principal 1, ainsi que des moyens (non représentés) de récupération de réponses du serveur principal 1 à ces requêtes. La figure 4 présente un organigramme simplifié d'un mode de réalisation particulier du procédé selon l'invention de développement d'une application multimédia. Ce procédé comprend, dans ce mode de réalisation, les étapes suivantes: - on utilise (44) le poste de gestion 2 pour définir une politique de gestion de données et une logique de navigation entre objets propres à une application multimédia. Pour cela, on création ou on modifie, dans le gestionnaire de relations 31 du moteur relationnel 12 du serveur principal 1, un ensemble de relations propre à une application multimédia; - on utilise (45) un poste de développement 4,5 pour développer une application multimédia en y incorporant, via l'appel des fonctions externes 42, 52 au moyen d'une commande spécifique (Xobjet, Librairies), la politique de gestion de données et la logique de navigation entre objets propres définies pour cette application multimédia lors de l'étape précédente 44. Ensuite, il existe deux possibilités correspondant chacune à la production d'un type distinct d'application multimédia finale, pouvant être exécutée respectivement en ligne (on line) ou de façon autonome (off line): - soit on génère (46), à partir de l'application multimédia préalablement développée, une application multimédia finale destinée à être supportée par un poste de consultation 6, 7 relié au serveur principal 1, de façon que cette application multimédia finale communique en ligne ("on-line") avec le serveur principal 1 lors de son exécution; - soit on génère (47), à partir de l'application multimédia préalablement développée, une application multimédia finale destinée à être stockée sur un support physique (CD ROM 9) stockant également le contenu à un instant donné du serveur principal 1, de façon que cette application multimédia finale s'exécute de façon autonome ("off-line"). Les deux possibilités discutées ci-dessus peuvent bien sûr être mises en oeuvre toutes les deux, de façon à diffuser l'application multimédia précédemment développée aussi bien en ligne (on line) que de façon autonome (off line). La figure 5 présente un organigramme simplifié d'un mode de réalisation particulier du procédé selon l'invention de mise àjour de données. Ce procédé comprend une unique étape 54 de mise àjour des données de la base de données. En effet, du fait de la structure du système de l'invention, il n'est pas nécessaire de reprogrammer les applications multimédias. Toutes les applications en cours de développement bénéficie en temps réel et simultanément de cette mise àjour. Par ailleurs, pour les applications multimédias finales, on distingue selon que celle-ci est exécutée "on line" ou "off line". Dans le premier cas (exécution "on line"), aucune manipulation n'est nécessaire : toutes les applications en cours d'exécution disposent instantanément et simultanément des données mises à jour. Dans le second cas (exécution "off line"), il suffit de reprendre le programme précédent (puisqu'il n'est pas modifié) et de stocker le nouveau contenu du serveur principal 1 (qui incorpore la mise àjour). La figure 6 présente un organigramme simplifié de l'exécution d'une commande du gestionnaire de relations 31 du moteur relationnel 12. I1 s'agit de la commande "LOADREL", qui permet à un poste 2, 4 à 7 (ou au serveur de consultation 8) de charger une relation. Lorsqu'un poste a besoin de travailler sur une relation (71), il se déroule le mécanisme suivant, basé sur la réponse à la question initiale (72): la relation a déjà été chargée ? Si oui, recherche (73) si les données correspondant à cette relation ont été modifiées depuis leur dernière utilisation: - si non, traitement local (74); - si oui, recherche (75) si les données sont locales (c'est-à-dire se trouvent dans une mémoire locale du poste: * si oui, chargement (76), mise à jour (77) de la date de modification et traitement local (74); * si non, les données sont donc externes et le système les trouve automatiquement en faisant les opérations suivantes: - construction (78) du paramètre qui décrit l'accès au répertoire associé à cette relation; - envoi (79) d'une requête au serveur principal avec le passage du paramètre du chemin d'accès; - le serveur principal effectue (80) le chargement des données et les renvoie au poste demandeur dans une mémoire locale, ar l'intermédiaire d'un pointeur de pointeur (Handle); - le serveur principal acquitte (81) et retourne la date de modification; - traitement local (74); * si non, recherche (75) si les données sont locales (cf ci-dessus). Dans un but de simplification, il n'a été fait mention que d'un poste dialoguant avec le serveur principal, mais on comprend bien que ce mécanisme peut se dérouler simultanément entre le serveur principal et plusieurs postes pour des applications différentes. REVENDICATIONS 1. Système de développement et/ou d'exécution d'applications multimédias mettant chacune en oeuvre notamment des fonctions d'animation graphique d'objets, une politique de gestion de données et une logique de navigation entre objets, caractérisé en ce qu'il comprend: un serveur principal (1) incluant un moteur relationnel (12) associé à une base de données relationnelle contenant des données à intégrer dans des applications multimédias, ledit moteur relationnel comprenant notamment: * un gestionnaire de relations (31), constituant le noyau de ladite base de données relationnelle et comprenant au moins un ensemble de relations, chaque ensemble de relations définissant une politique de gestion de données et une logique de navigation entre objets propres à chaque application multimédia ; et * un gestionnaire de saisie interactive (32), permettant la création et/ou la modification de chaque ensemble de relations; au moins un poste de gestion (2), relié audit serveur principal (1) via des interfaces de communication (13, 23) et supportant un premier produit multimédia (Hypercard ; 21) auquel sont adjointes les fonctionnalités dudit moteur relationnel (12) sous forme de fonctions externes (22) pouvant être appelées au moyen d'une commande spécifique (XCMD) du langage de programmation (Hypertalk) propre audit premier produit multimédia, ledit premier produit multimédia (21) utilisant lesdites fonctions externes (22) pour créer et/ou modifier chaque ensemble de relations; - au moins un poste de développement (4, 5), relié audit serveur principal (1) via des interfaces de communication (13, 43, 53) et supportant un second produit multimédia (Hypercard, Director, Apple Media Tool ; 41, 51) auquel sont adjointes les fonctionnalités dudit moteur relationnel (12) sous forme de fonctions externes (42, 52) pouvant être appelées au moyen d'une commande spécifique (XCMD, Xobjet, Librairies) du langage de programmation (Hypertalk, Lingo, K) propre audit second produit multimédia, ledit second produit multimédia (41, 51) utilisant lesdites fonctions externes (42, 52) pour que l'application multimédia qu'il permet de développer mette en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur ledit serveur principal (1). 2. Système selon la revendication 1, caractérisé en ce qu'il comprend également au moins un poste de consultation (6, 7), relié audit serveur principal (1) via des interfaces de communication (13, 63, 73) et supportant une application multimédia finale (ou runtime) (61, 71) incluant une version exécutable du second produit multimédia (Hypercard, Director, Apple Media Tool) sous lequel elle a été développée et auquel sont adjointes les fonctionnalités dudit moteur relationnel (12) sous forme de fonctions externes (62, 72), ladite application multimédia finale (61, 71) utilisant lesdites fonctions externes pour mettre en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur ledit serveur principal (1). 3. Système selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'il comprend également au moins un serveur de consultation (8) appartenant à un réseau externe (Internet), ledit serveur de consultation étant relié audit serveur principal (1) via des interfaces de communication (13, 83) et supportant une application multimédia finale (81) exécutable sous un troisième produit multimédia (Webstar) auquel sont adjointes les fonctionnalités dudit moteur relationnel (12) sous forme de fonctions externes (82) pouvant être appelées au moyen d'une commande spécifique (cgi), ladite application multimédia finale (81) utilisant lesdites fonctions externes (82) pour mettre en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur ledit serveur principal (1). 4. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit poste de gestion (2) et/ou ledit poste de développement (4, 5) et/ou ledit poste de consultation (6, 7) et/ou ledit serveur de consultation (8) sont reliés audit serveur principal (1) par l'intermédiaire d'un réseau (10). 5. Système selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit serveur principal, ledit poste de gestion, ledit poste de développement, ledit poste de consultation et ledit serveur de consultation sont regroupés sur une même station de travail. 6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit moteur relationnel (12) comprend également au moins un des gestionnaires appartenant au groupe comprenant: - un gestionnaire de schéma (33), permettant de décrire les liens qui existent entre les relations d'une application multimédia; - un gestionnaire de listes (34), permettant la présentation et/ou la visualisation d'éléments, en travaillant sur les liens récupérés depuis ledit serveur principal en mémoire locale d'un desdits postes de gestion, développement ou consultation ou dudit serveur de consultation; - un gestionnaire d'utilitaire système (35), permettant de faire tout type de manipulation de fichiers dans le serveur principal et et traiter tout type de chaînes de caractères dans les fichiers; - un gestionnaire de statistiques (36), permettant de mettre en oeuvre un ensemble de fonctionnalités d'exploitation et/ou de statistiques; - un gestionnaire d'impression (37), permettant de prendre en charge les impressions, de façon indépendante des applications multimédias. 7. Système selon l'une quelconque des revendications 1 à 6, caractérisé en ce que lesdites fonctions externes (22, 42, 52, 62, 72, 82) comprennent des moyens de construction et d'envoi de requêtes audit serveur principal (1), ainsi que des moyens de récupération de réponses dudit serveur principal auxdites requêtes. 8. Système selon l'une quelconque des revendications 1 à 7, caractérisé en ce que les données de ladite base de données sont stockées sur le serveur principal (1) ou réparties entre le serveur principal et le poste de gestion (2) et/ou le poste de développement (4, 5) et/ou le poste de consultation (6, 7) et/ou le serveur de consultation (8). 9. Système de développement et/ou d'exécution d'applications multimédias mettant chacune en oeuvre notamment des fonctions d'animation graphique d'objets, une politique de gestion de données et une logique de navigation entre objets, caractérisé en ce qu'il comprend une station de travail unique incluant: - au moins une application de gestion supportant un premier produit multimédia (Hypercard) auquel sont adjointes les fonctionnalités d'un moteur relationnel sous forme de fonctions externes pouvant être appelées au moyen d'une commande spécifique (XCMD) du langage de programmation (Hypertalk) propre audit premier produit multimédia, ledit premier produit multimédia utilisant lesdites fonctions externes pour créer et/ou modifier chaque ensemble de relations, ledit moteur relationnel étant associé à une base de données relationnelle contenant des données à intégrer dans des applications multimédias, ledit moteur relationnel comprenant notamment: * un gestionnaire de relations, constituant le noyau de ladite base de données relationnelle et comprenant au moins un ensemble de relations, chaque ensemble de relations définissant une politique de gestion de données et une logique de navigation entre objets propres à chaque application multimédia et * un gestionnaire de saisie interactive, permettant la création et/ou la modification de chaque ensemble de relations au moins une application de développement, relié à ladite application de gestion via des interfaces de communication, et supportant un second produit multimédia (Hypercard, Director, Apple Media Tool) auquel sont adjointes les fonctionnalités dudit moteur relationnel sous forme de fonctions externes pouvant être appelées au moyen d'une commande spécifique (XCMD, Xobjet, Librairies) du langage de programmation (Hypertalk, Lingo, K) propre audit second produit multimédia, ledit second produit multimédia utilisant lesdites fonctions externes pour que l'application multimédia qu'il permet de développer mette en oeuvre une politique de gestion de données et une logique de navigation entre objets qui lui sont propres et qui sont déportées sur ladite application de gestion. 10. Procédé de développement d'une application multimédia dans un système selon l'une quelconque des revendications 1 à 8, caractérisé en ce qu'il comprend les étapes suivantes: - on utilise (44) le poste de gestion pour définir une politique de gestion de données et une logique de navigation entre objets propres à une application multimédia, par création et/ou modification, dans le gestionnaire de relations du moteur relationnel du serveur principal, d'un ensemble de relations propre à une application multimédia; - on utilise (45) le poste de développement pour développer une application multimédia en y incorporant, via l'appel des fonctions externes au moyen de ladite commande spécifique, la politique de gestion de données et la logique de navigation entre objets propres définies pour ladite application multimédia lors de l'étape précédente. 1 1. Procédé selon la revendication 10, caractérisé en ce qu'il comprend également une étape (46) de génération, à partir de l'application multimédia préalablement développée, d'une application multimédia finale destinée à être supportée par un poste de consultation relié audit serveur principal, de façon que ladite application multimédia finale communique en ligne ("on-line") avec ledit serveur principal lors de son exécution. 12. Procédé selon la revendication 10, caractérisé en ce qu'il comprend également une étape (47) de génération, à partir de l'application multimédia préalablement développée, d'une application multimédia finale destinée à être stockée sur un support physique (CD ROM, borne interactive) stockant également le contenu à un instant donné dudit serveur principal, de façon que ladite application multimédia finale s'exécute de façon autonome ("off-line"). 13. Procédé de mise à jour de données d'applications multimédias développées et/ou exécutées dans un système selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend une étape (54) de mise à jour des données de ladite base de données.