FR 2913293 A1 20080905 FR 0756442 A 20070712 Domaine de l'invention La présente invention se rapporte au domaine 5 des technologies de l'information et de la communication. La présente invention se rapporte plus particulièrement à un système d'informations pour l'environnement de diffusion audio/vidéo ( broadcast ), 10 comportant des moyens pour la gestion de sites distants. Etat de la technique L'environnement de production broadcast a 15 été jusqu'à présent limité au périmètre du Studio ou à un ensemble de studios d'un même site. Les organisations des chaînes nationales voire supra nationales sont réparties sur plusieurs sites. Elles nécessitent d'échanger des informations de plus en 20 plus loin et toujours plus vite. La mutualisation des ressources, le travail en mode partagé et en décalé, la réactivité représentent des avantages compétitifs majeurs. Les technologies réseaux de moins en moins 25 coûteuses et de plus en plus rapides offrent une opportunité de mailler les applications pour fonctionner en mode coopératif. Les solutions réseau mises en place ne présentent pas toutes le même niveau de sécurité et de 30 performance s'échelonnant du réseau privé à très haut débit à l'utilisation du réseau public aux débits inconstants et ouverts à toutes les ingérences. Avant et après mise en service, les éventuels dysfonctionnements du réseau dégradent les applications 35 sans possibilité de trancher la responsabilité entre le réseau et les applications. L'analyse est alors délicate voire impossible et le diagnostique retardée pour mettre en place des actions correctives. Les solutions de gestion de production broadcast pour les studios intègrent toujours plus d'équipements informatiques au sein du réseau local (LAN). Les données et les contenus vidéo créés se présentent sous forme de fichiers occupant des volumes toujours croissants qui doivent être indexés pour disposer d'un référencement global au sein d'organisations transnationales. Avec la diminution de leurs coûts technologiques et l'accroissement de leurs performances, les réseaux TCP/IP facilitent les échanges de grands volumes de données sans perte entre réseaux locaux. Il devient envisageable d'étendre la gestion de production du LAN vers leur interconnexion aux travers de réseaux de contribution WAN. Le système de production broadcast peut alors sortir des frontières d'un simple studio à un travail en mode coopératif entre studios grâce à des échanges fondés sur les réseaux TCP/IP. Les réseaux de contribution présentent encore aujourd'hui deux points faibles majeurs par rapport au LAN : des bandes passantes réduites et des problèmes sécurité qui peuvent porter atteinte aléatoirement et insidieusement au niveau applicatif. Pour mieux maîtriser les interactions entre le réseau et les applicatifs, il est nécessaire de construire une solution middleware qui permette de fiabiliser, d'administrer et de superviser les échanges des applications clientes. Pour atteindre cet objectif, il est nécessaire de . • Définir un service réseau sécurisé et fiable pour les applications clientes • Répartir les flux transportés entre deux protocoles : l'un de signalisation et l'autre de transfert de données • Définir un Modèle du réseau pour fixer des règles de gestion du trafic • Planifier les demandes du transfert en fonction des règles de gestion pour réguler le trafic • Mettre à disposition une supervision temps réel performante de toutes les ressources • Présenter en temps réel des indicateurs réel quantifiant les gains de la régulation de trafic • Centraliser et hiérarchiser la présentation des données à administrer. Les données à échanger entre les applications broadcast se répartissent dans les catégories suivantes: • Les médias avec des tailles allant de quelques Kilo octets à plusieurs Giga octets avec (mode flux temps réel) ou sans contraintes temps réel (mode fichier). • Les données annexées aux médias appelées méta données de taille réduite 25 • Les données techniques de référencement des données produites et de synchronisation de nature temps réel. Pour proposer un environnement d'échange de 30 données coopératif et centralisé aux applications, il est indispensable de les hiérarchiser pour les transporter selon des protocoles d'échanges adaptés à leurs spécificités. 35 Le référentiel des données gérées par ses solutions se limite à un serveur des bases de données qui 10 15 20 permet d'indexer tous les contenus des stockages déclarés sur le LAN. Pour étendre la gestion de production à des sites distants interconnectés via réseau TCP/IP, plusieurs solutions d'architecture sont possibles : Répliquer les bases données de sites à site. L'avantage est le gain en temps d'accès à la donnée répliquée en local. Les inconvénients sont la gestion des réplications avec les latences des cycles et les perturbations dues aux incidents du réseau, l'utilisation non optimisée en raison d'une duplication systématique des données, l'augmentation des volumes de stockage pour réplication soit d'un facteur égal à Nombre sites * nombre de stockages distants à répliquer. Disposer d'un serveur centralisant l'indexation des données de tous les sites. L'avantage est d'optimiser les requêtes complexes de bases de données sur un référencement centralisé. Les inconvénients sont liés au talon d'Achille que constitue la disponibilité de l'unique serveur soit en raison d'une éventuelle panne soit en raison des dysfonctionnements du réseau pour être interrogé à distance. Le palliatif partiel consiste à le redonder avec un alourdissement des investissements. Exposé de l'invention La présente invention propose de hiérarchiser les interfaces entre applications et réseau en s'intégrant comme une couche middleware intermédiaire pour : • Transporter les classes de services entre les applications • Superviser les différents protocoles 35 utilisés pour apprécier en temps réel la performance du réseau. • Réguler le trafic FTP requis par les applications clients pour utiliser les ressources dans les limites de leur capacité. La présente invention offre une solution de compromis entre : • Bénéficier d'une infrastructure réseau sécurisée pour permettre une recherche transparente pour les utilisateurs quelle que soit la localisation de la base de données. La centralisation du référencement est virtuelle et ne demande pas de répliquer des bases des données au travers du réseau. • Optimiser les ressources réseau pour ne le solliciter que pour les transferts de données à la demande. • Modéliser les ressources réseau sollicitées pour les échanges de bout en bout et paramétrer des règles de gestion de trafic. Bâtir sur ces règles une régulation du trafic permettant de planifier les demandes de transferts et d'avoir différents niveaux de priorités pour les demandes. • Ne pas ajouter de bases de données supplémentaires pour centraliser les données à répliquer avec tous les inconvénients de synchronisation qu'il faut alors gérer. • Avoir des manageurs du réseau qui soient des machines serveurs informatiques standard peu coûteuses et jouant tous le même rôle. En cas d'indisponibilité d'un manageur, seul les informations et les clients du manageur sont indisponibles. 35 Les inconvénients restent : 15 20 25 30 Pas de référentiel d'indexation globalisé pour permettre des requêtes de recherche complexe (exemple donner toutes les occurrences du média qui existent à New York moins les occurrences identiques localisées à Paris) Les temps d'accès aux données distantes sont augmentés du temps de transfert réseau. Pour minimiser le dernier inconvénient qui impacte aussi les réplications de données utilisées par les autres solutions, un effort de développement très important a été apporté sur la supervision des protocoles utilisés par le système selon la présente invention. Les métriques sur le comportement du réseau sont collectées en temps réel à partir des messages inclus à la fois dans le trafic de données et dans celui de la signalisation. Ils sont visualisables sous forme de rapports ou de graphiques. Une modélisation des ressources réseau offre un support pour décrire leurs capacités de transfert et ainsi garantir une régulation de trafic des donnés. Le problème technique que la présente invention se propose de résoudre consiste à améliorer la gestion de 25 données vidéo exploitées sur des serveurs distants. La présente invention concerne, dans son acception la plus générale, un système d'informations pour un environnement de diffusion audio/vidéo 30 ( broadcast ), comportant au moins deux serveurs reliés entre eux par un réseau de communication, des applications clientes informatiques se connectant aux dits serveurs, caractérisé en ce qu'il comprend : • des moyens pour accéder depuis un 35 serveur à des données contrôlées par un autre serveur ; • des moyens pour échanger des messages entre serveurs ; • des moyens pour échanger des données entre des applications s'exécutant sur différents serveurs ; et • des moyens de visualisation d'indicateurs liés aux ressources du réseau et des serveurs. De préférence, au moins un des indicateurs porte sur le temps de réponse du réseau. Avantageusement, au moins un des indicateurs porte sur le délai de réception de données par les applications informatiques. Selon un mode de réalisation, les échanges de données s'effectuent selon le protocole FTP (File Transfer Protocol). Selon un mode de mise en oeuvre particulier, les échanges de messages sont réalisés au moyen du protocole 20 Message Queuing de la société Microsoft. Selon une variante, les données à échanger sont réparties en deux flux : • la signalisation qui inclut des ordres de transfert de données, des messages 25 techniques propres au système et des classes de services des applications informatiques ; et • les transferts de données pour transporter les données en mode fichier ou en mode 30 flux. De préférence, ledit système comporte des moyens d'observation en temps réel des serveurs et du réseau. Avantageusement, ladite observation est 35 matérialisée sous la forme de représentation graphique ou de rapports. Selon un mode de réalisation, ledit système comporte des moyens pour modéliser des ressources du réseau afin de réguler le trafic FTP. De préférence, ledit système comporte des 5 moyens pour centraliser l'intégralité du trafic FTP afin d'effectuer une reprise en mode manuel de la planification. Dans des modes de réalisations particuliers, la présente invention comprend : 10 • Des moyens pour modéliser les ressources réseau sollicitées par les échanges de fichiers de données ; et/ou • Des moyens pour contrôler ou planifier automatiquement le trafic ; et/ou 15 • Des moyens pour visualiser et permettre la reprise manuelle de la planification du trafic. 20 La présente invention possède de nombreux avantages, parmi lesquels on trouve : • Retour sur investissement : 25 Le système selon la présente invention réduit les coûts de développement et d'implémentation d'une solution réseau pour les applications. Le paramétrage de la configuration est aisé et les procédures d'installations sont simplifiées grâce 30 à un haut degré d'automatisation et d'assistance des étapes de configuration. Le système selon la présente invention sert d'intermédiaire entre les applications logicielles et de tampon entre l'applicatif et l'architecture réseau qu'il rend 35 transparent. Il permet l'évolutivité du système d'information en permettant l'ajout de nouveaux services et en découplant l'application cliente de l'accès aux données et services du réseau. Le système selon la présente invention tend à réduire les coûts de perte d'opportunité. La mise en oeuvre indépendante de la disponibilité des applications clientes à venir permet valider les ressources réseau en amont de la mise en exploitation. Le système selon la présente invention aide à maîtriser les coûts de maintenance en offrant une grande visibilité sur les interactions entre les couches application et réseau. Les indicateurs réels permettent de quantifier isolément les comportements de chaque ressource et d'en déduire rapidement le bon diagnostique. Le système selon la présente invention permet de réduire les pénalités liées à l'entrave à l'exploitation. La régulation de trafic limite et lisse les demandes des applications pour maintenir en toutes circonstances la disponibilité du réseau. Le système selon la présente invention aide à anticiper l'ajustement des investissements présents et futurs. Les métriques de trafic fournissent une image détaillée et en temps réel de fluctuations des flux d'exploitation pour faciliter l'ajustement des ressources réseau aux besoins présents et futurs. 30 • Solution d'échanges sur tout réseau TCP/IP Le système selon la présente invention fournit un réseau de transport sur TCP/IP de classes de services applications et de leurs données pour des échanges sécurisés sur un mode coopératif 35 et égalitaire. 25 Le réseau dans le cadre du système selon la présente invention peut être déployé sur tout réseau TCP/IP (LAN/WAN) privé ou public. • Flux d'échanges hiérarchisés : Les données produites par les utilisateurs de l'application sont transportées sous protocole FTP. Tous les transferts FTP entre stockages sur réseau sont sécurisés. La synchronisation des serveurs FTP pris en charge par le système selon la présente invention. Les contrôles FTP sont transportés dans le protocole de signalisation dans le cadre du système selon la présente invention et les données d'identification et d'authentification ne transitent pas entre serveurs sous le protocole FTP. Les transferts FTP peuvent intervenir entre deux serveurs appartenant ou non (routage et translation d'adresse) au même réseau local. Le protocole de signalisation dans le cadre du système selon la présente invention transporte les données techniques et ordres du système selon la présente invention et les classes de service des applications. Les contenus des messages de classes de services ne sont pas interprétés. Le protocole de signalisation est compatible avec les translations d'adresses et les pare-feux ( Firewalls ) mis en place au niveau de routeur. • Réseau contrôlé pour tout serveur FTP : Accepter tout serveur FTP respectant l'implémentation standard et garantir la synchronisation des serveurs FTP sans utiliser les protocoles FTP de contrôle sur le réseau WAN (les contrôles sont échangés via le protocole de signalisation du système selon la présente invention). Accepter des échanges entre serveurs FTP appartenant au même LAN ou des FTP serveurs distants interconnectés via un WAN. • Régulation du trafic : Permettre de caractériser le réseau pour paramétrer la gestion des transferts des données de bout en bout. Les requêtes de transfert immédiates ou programmées sont planifiées selon la disponibilité des ressources réseau, les caractéristiques des fichiers de données et leur niveau de priorité. Pouvoir mettre en attente des demandes de transferts ou les exécuter immédiatement en mode prioritaire. • Configuration distribuée et centralisée : Les serveurs dans le cadre du système selon la présente invention répliquent la configuration partagée de manageur à manageur chaque fois que l'un se connecte à l'infrastructure ou que la configuration est modifiée sur l'un des Manageur connecté. Dans ce mode multi maîtres, la configuration la plus récente écrase les versions plus anciennes. • Supervision de toutes les ressources en temps réel : Toutes ressources surveillées : Supervision et configuration des équipements et services gérés par le système selon la présente invention : serveurs FTP, manageurs du système selon la présente invention en temps à partir de vues graphiques personnalisables. Vues supervision hiérarchisées La vue de supervision de plus haut niveau présente tous les manageurs du système selon la présente invention avec les liaisons réseau. Trois zones graphiques permettent l'accès à des menus contextuels de visualisation et de configuration des données par manageur, des données liaison réseau, des données communes à tous les manageurs. Vues des clients personnalisables : Les vues pour supervision des clients de chaque manageur du système selon la présente invention sont personnalisables à partir de schémas importés édités sous Visio (marque déposée) de Microsoft (marque déposée). Chaque type d'équipement peut être représenté sous une icône spécifique pour laquelle est configurée une adresse IP. La vue animée permet de visualiser l'état et d'afficher des menus contextuels de visualisation et de configuration. Un rapprochement entre les identifiants des équipements configurés dans la vue et ceux détectés permet de d'animer et de détecter des évolutions/états du parc dans le cadre du système selon la présente invention. Traces de tous les flux réseau échangés : Toutes classes de services clients et les ordres du système selon la présente invention (principalement), toutes les demandes de transferts FTP en attente et en cours de réalisation sont tracées pour être disponibles en consultation à court terme puis sont archivées à plus long terme pour consultation sur la plage temporelle requise. Une liste de trace (rapport concernant les requêtes FTP effectuées ou AsRunLog ) consigne uniquement les demandes de transferts FTP pour tout usage de PLM ou de facturation et est gérée de la même façon que la trace globale. Un historique de toutes les commandes terminées quel que soit leur état d'achèvement obéit aux mêmes règles de consultation que la trace globale et le rapport concernant les requêtes FTP effectuées ( AsRunLog ). Gestion événements centralisée : Les erreurs, les avertissements, ou les autres évènements sont consignés par chaque Manageur du système selon la présente invention et par chaque application d'administration du système selon la présente invention, dans son propre fichier d'événements Windows (marque déposée). La consultation centralisée permet d'accéder à partir d'un poste à touts les fichiers d'événements. La description des erreurs logicielles inclut l'identification du module émetteur, la date, la version logicielle et le contexte programme de l'erreur pour fournir des informations exhaustives au dépannage du logiciel. • Services de maintenance : Aide au diagnostique des incidents : la description sur les causes probables et les remèdes à apporter peut être enrichie indépendamment des livraisons de versions logiciels pour faire bénéficier des avancées de l'intégration et des résolutions d'incidents sur d' autres implantations. Maintenance avec le déploiement à distance de version du logiciel des serveurs, dans le cadre du système selon la présente invention : les mises à jour de logiciel des serveurs dans le cadre du système selon la présente invention peuvent être déployées à partir de n'importe quelle console administrateur. Tout administrateur peut programmer un déploiement à l'ensemble des Manageurs du système selon la présente invention mais doit solliciter l'approbation de la programmation de chacun des Administrateur de domaine à moins qu'il n'ait le rôle d'administrer l'ensemble de l'infrastructure dans le cadre du système selon la présente invention. L'administrateur supervise et configure les équipements qui supportent les services FTP contrôlés par le système selon la présente invention. Les vues pour superviser les équipements peuvent 5 être construites à partir de l'éditeur Visio (marque déposée) système de Microsoft (marque déposée). Les schémas sont importables pour servir de vues au monitoring équipements 10 contextuels et monter l'état des services embarqués. Un entre les adresses IP configurées pour les détectées par apparaître des de paramétrage : représentation graphique détectée sous une autre adresse, l'état indisponible d'un équipement qui ne répond pas à des interrogations du manageur dans le cadre du système selon la présente invention. Brève description des dessins On comprendra mieux l'invention à l'aide de la description, faite ci-après à titre purement explicatif, 25 d'un mode de réalisation de l'invention, en référence aux dessins annexés, dans lesquels : • la Figure 1 illustre les groupes et rôles des administrateurs du système selon la présente invention enregistrés dans le répertoire Active Directory • la Figure 2 représente la configuration du service FTP ( File Transfer Protocol ) clients du serveur ; • la Figure 3 illustre la programmation de déploiement de version du système selon la présente invention ; et les représentations graphiques des sont animées pour accéder à des menus rapprochement équipements l'application incohérences représentés et ceux cliente permet de faire d'un équipement visualisation de 15 20 30 35 10 15 20 25 30 • la Figure 4 illustre la gestion des serveurs référencés dans le réseau, dans le cadre du système selon la présente invention ; • la Figure 5 représente un écran de paramétrage du trafic FTP ; • la Figure 6 illustre les paramètres de configuration d'un service FTP ; • la Figure 7 illustre un écran de planification de transferts FTP ; • la Figure 8 est une vue générale avec un LAN ( Local Area Network ) et les liaisons réseau avec les autres serveurs ou LANs ; • la Figure 9 est une vue détaillée de l'environnement d'un serveur, dans le cadre du système selon la présente invention ; • la Figure 10 représente un serveur actif, autorisant les échanges clients avec les autres serveurs ; • la Figure 11 illustre un LAN actif dans lequel au moins un des serveurs inclus est actif ; • la Figure 12 illustre un serveur actif mais qui interdit les requêtes avec les autres serveurs ; • la Figure 13 représente un serveur non opérationnel ; • la Figure 14 représente une liaison permettant des échanges de messages de signalisation et de données FTP ; • la Figure 15 représente une liaison avec interruption de la signalisation ; 10 15 20 25 30 35 • la Figure 16 illustre une liaison permettant les échanges de messages de signalisation mais pas de données sous le protocole FTP ; • la Figure 17 illustre un cercle serveur, dans le cadre du système selon la présente invention, et l'accès à la visualisation des états/traces et à la configuration relatives au serveur ; • la Figure 18 représente une zone commune hors serveur et l'accès à la visualisation des états/traces et à la configuration de toute l'infrastructure ; • la Figure 19 illustre une liste de menus contextuels par équipement ; • la Figure 20 illustre l'affichage des requêtes en attente, en cours ou terminées d'un serveur, dans le cadre du système selon la présente invention ; • la Figure 21 représente un rapport concernant les requêtes FTP effectuées ( AsRunLog ) ; • la Figure 22 représente un rapport concernant les temps aller/retour de signalisation ; • la Figure 23 illustre un rapport concernant la taille des messages et le débit par classe de service ; • la Figure 24 illustre un graphique représentant le débit de la signalisation ; • la Figure 25 représente des indicateurs de qualité de régulation du trafic FTP ; • la Figure 26 illustre le choix du serveur pour afficher un rapport concernant des événements ( EventLog ) ; • la Figure 27 représente un rapport concernant des événements ( EventLog ) ainsi qu'une fenêtre d'aide au diagnostic ; • la Figure 28 illustre un script d'installation du système selon la présente invention avec un message d'avertissement ; • la Figure 29 illustre un masque de saisie de la clé d'authentification lors de l'installation ; et • la Figure 30 représente la programmation de déploiement à distance du système selon la présente invention. 20 Description détaillée des modes de réalisation de l'invention Dans le domaine de la diffusion de contenu vidéo (broadcast), le système selon la présente invention 25 offre ses services à des applications pour permettre la consultation des bases de données médias disséminées au sein de différents studios. Depuis n'importe quel poste comportant certaines applications, un opérateur peut explorer, 30 rechercher, pré-visualiser les médias et les métadonnées associées de tous les stockages indexés par les différentes bases de données. Une fois un média identifié et localisé, un opérateur peut demander son transfert entre tous les 35 stockages auxquels sont attachés au moins un serveur FTP contrôlable par le système selon la présente invention. 10 15 Le transfert des médias est réalisé à la demande en mode immédiat ou programmé selon le débit minimal garanti et défini par le paramétrage de la régulation de trafic. Un niveau prioritaire permet de demander un transfert qui sera exécuté immédiatement en s'affranchissant des limites de la régulation. L'exécution de ce transfert, s'il conduit à dépasser les limites fixées partagera la bande passante avec les autres transferts en cours et dégradera d'autant la part de bande passante alloué à chacun. Toutefois, le nombre de transferts simultanés y compris le prioritaire ne pourra excéder la limite d'au plus un. Si les ressources sont disponibles, le transfert prioritaire s'exécute en passant devant les demandes déjà en attente. Le lancement des demandes en attentes pourrait en être retardé. La planification déjà programmée n'est 20 pas recalculée pour tenir compte de cette perturbation. La configuration du réseau de serveurs dans le cadre du système selon la présente invention consiste à : Ajouter/supprimer des serveurs dans le cadre du 25 système selon la présente invention à son réseau existant en déclarant l'adresse IP de la station. Pour des raisons de sécurité, les serveurs ne peuvent établir de communication qu'avec des serveurs qui partagent la même clé d'authentification. La section qui concerne le 30 déploiement de versions logicielles décrit comment le paramétrage de cette clé est effectué. Paramétrer les références des services FTP contrôlés par les serveurs dans le cadre du système selon la présente invention 35 Paramétrer les règles de gestion de la régulation du trafic FTP Interdire/autoriser les échanges de requêtes clientes avec les autres serveurs Programmer le déploiement des versions du logiciel serveur dans le cadre du système selon la présente invention (on peut se reporter à la section qui concerne le déploiement de versions logicielles). L'accessibilité à ces contrôles dépend du rôle attribué au compte utilisateur sous Windows (marque déposée). Le profil de l'utilisateur est déterminé au moment de l'identification d'ouverture de session Windows (marque déposée) à partir des attributs du groupe de sécurité d'appartenance défini au niveau du contrôleur de domaine Windows (marque déposée). Le rattachement d'un compte utilisateur à l'un des deux groupes d'administrateur dans le cadre du système selon la présente invention est sous la responsabilité de l'administrateur IT du domaine Windows (marque déposée). Un utilisateur n'appartenant à aucun des deux groupes définis ci après peut visualiser toutes les données d'administration dans le cadre du système selon la présente invention mais ne peut les modifier. Certains menus ne lui sont pas accessibles. Les groupes d'administrateur dans le cadre du système selon la présenteinvention et leurs rôles attribués sont enregistrés dans un répertoire appelé Active Directory du contrôleur de domaine Windows (marque déposée) (on se référera pour cela à la Figure 1) . Administrateurs des serveurs appartenant au même domaine Windows (marque déposée) que l'administrateur Administrateur de l'ensemble des serveurs quel que soit leur domaine Windows (marque déposée) d'appartenance. La Figure 1 illustre les groupes et rôles des administrateurs du système selon la présente invention enregistrés dans le répertoire Active Directory . Un administrateur avec un rôle limité à un domaine Windows (marque déposée) n'a autorité que sur les serveurs qui appartiennent à son domaine pour : Configurer les services clients du serveur dans le cadre du système selon la présente invention (service FTP, référence logique pour le stockage) (on se réfèrera pour cela à la Figure 2) ; Approuver les demandes de déploiement de logiciel issues de serveurs hors de son domaine ; Autoriser/interdire les échanges de classes de services avec les autres serveurs hors de son domaine. La Figure 2 représente la configuration du service FTP ( File Transfer Protocol ) clients du serveur et la Figure 3 illustre la programmation de déploiement de version du système selon la présente invention. L'administrateur avec autorité sur tous les serveurs dans le cadre du système selon la présente invention peut aussi gérer les données de configuration communes à tous les serveurs pour : ajouter/supprimer des références de serveurs au réseau dans le cadre du système selon la présente invention ; Modifier le paramétrage de la régulation de 35 trafic FTP. La Figure 4 illustre la gestion des serveurs référencés dans le réseau, dans le cadre du système selon la présente invention. Le protocole TCP/IP a la capacité de répartir la bande passante du réseau équitablement entre les flux de données en cours d'échange. Son point faible est la reprise des échanges en cas de congestion du réseau. Le système selon la présente invention tire profit de l'équilibrage des flux réalisé par TCP/IP : Evite la congestion de trafic en paramétrant toutes les ressources réseau qui participent aux échanges de données. Ce modèle paramétrable permet de contrôler et de réguler de bout en bout les transferts requis par les applications. Garantit le débit minimum de chaque transfert. A charge de l'administrateur de définir le débit minimum à garantir pour chaque transfert FTP. A charge de l'architecte réseau de garantir le débit utile au niveau de chaque ressource décrite par le modèle. Les ressources du modèle sont : Les serveurs FTP avec en paramètre le nombre maximum de transactions FTP simultanées en écriture et/ou 25 en lecture. Les liaisons entre serveurs FTP rattachés à chacun des serveurs dans le cadre du système selon la présente invention avec en paramètre le nombre maximum de transactions FTP simultanées pour chaque sens. 30 La passerelle LAN vers WAN avec en paramètre le nombre maximum de transactions FTP simultanées entrantes et sortantes cumulées. La vue de la Figure 5 permet de paramétrer 35 l'ensemble des règles de gestion de trafic FTP. Elle présente une matrice 2 x 2 avec en vertical et horizontal les poids en nombre de transactions FTP des liaisons serveurs à serveurs, en diagonale le poids des passerelles de LAN / WAN de chaque serveur. Lorsque plusieurs serveurs appartiennent à un 5 même LAN, ils partagent la même passerelle. C'est le cas pour les serveurs MFNY2 et MFNY de la Figure 5. La Figure 5 représente un écran de paramétrage du trafic FTP Le nombre de transactions simultanées par serveur FTP est configuré au niveau de chaque service FTP rattaché à chacun des serveurs dans le cadre du système selon la présente invention. 15 La Figure 6 illustre les paramètres de configuration d'un service FTP. Les requêtes de transferts FTP peuvent être à 20 exécution immédiate ou temporisée. Le contrôle d'admission des ces requêtes par le serveur est réalisé à 3 niveaux hiérarchiques : L'interprétation pour contrôle syntaxique 25 L'analyse pour vérifier la validité de la requêtes : existence de la donnée, droit sur la donnée, donnée accessible par les serveurs FTP gérés par le système selon la présente invention ... Ce niveau de contrôle nécessite des échanges de signalisation avec les 30 serveurs distants. L'allocation de la requêtes pour exécution soit immédiate soit différées sur demande du client ou par contrainte de planification en regard des règles de gestion du trafic définissant les disponibilités des 35 ressources réseau. Ce niveau de contrôle nécessite des échanges de signalisation avec les serveurs distants. 10 Le lancement des requêtes en file d'attente en fonction de leur programmation et de la disponibilité des ressources allouées. La libération tardive de ressources peut entraîner le lancement retardé de la programmation. L'ensemble des transferts à l'état en cours, en attente et terminées sont présentés Figure 7 centralisant la planification centralisée de toute l'infrastructure du système selon la présente invention. La Figure 7 illustre un écran de planification de transferts FTP. Chaque serveur dans le cadre du système selon 15 la présente invention doit être synchronisé sur l'heure UTC (Coordinated Universal Time) via tout moyen : serveur NTP (Network Time Protocol), carte d'entrée heure UTC ... L'heure de référence sert à : Dater les changements de configuration par 20 chaque serveur pour partager l'image de la configuration modifiée le plus récemment. Si l'un des serveurs n'est pas à l'heure, la comparaison des dates sera erronée. Programmer le déploiement de versions de logiciel à distance. Cette programmation est basée sur 25 l'heure UTC du serveur duquel émane la demande. Si un serveur n'est pas à l'heure, le déploiement sera programmé à une heure ne compensant pas la dérive locale. Programmer les transferts FTP. Les heures de tous les serveurs sont contrôlées cycliquement pour 30 compenser les éventuelles dérives entre serveurs. La programmation à venir tient compte des corrections. En revanche, la planification déjà programmée sera perturbée si les dérives sont importantes. Synchroniser les serveurs qui lancent les 35 ordres à adresser à leurs serveurs FTP respectifs (les transferts FTP impliquent toujours de synchroniser 2 serveurs FTP). 10 Une dérive ou modification d'heure UTC importante d'un serveur (normalement improbable) peut conduire à l'échec de lancement des planifications. Les lancements sur les différents serveurs ne sont plus simultanés et sont abandonnés grâce à des time out échus. L'affichage des heures peut être choisi en mode d'affichage UTC ou local. Le but du monitoring selon la présente invention est d'offrir à l'administrateur des informations synthétiques et de fournir un accès le plus direct possible grâce à une hiérarchisation des 15 informations visualisées et grâce à des menus contextuels . Vue générale (Figure 8) avec un serveur du système selon la présente invention et/ou avec un LAN en position centrale (un LAN regroupe plusieurs serveurs) et 20 leurs liaisons réseau avec tous les autres serveurs du système selon la présente invention et/ou les autres LAN. Vue intermédiaire détaillant les serveurs du système selon la présente invention regroupés dans un LAN et les liaisons réseau entre eux. 25 Vue détaillée (Figure 9) de l'environnement du serveur du système selon la présente invention avec les équipements/ services qu'il contrôle. La liste dans le cartouche de gauche avec une 30 colonne LAN et une colonne serveur permet de sélectionner le LAN s'il existe ou le serveur à afficher en position centrale. Si le serveur d'un LAN avec plusieurs serveurs, est affiché en position centrale, tous les autres serveurs sont représentés en périphérie, y compris ceux 35 de son LAN. 10 La Figure 8 est une vue générale avec un LAN ( Local Area Network ) et les liaisons réseau avec les autres serveurs ou LANs et la Figure 9 est une vue détaillée de l'environnement d'un serveur, dans le cadre du système selon la présente invention. Dans la vue générale, les serveurs sont représentés sous forme de disques avec une animation des états suivants : Serveur actif et autorisant les échanges clients avec les autres serveurs (Figure 10) ; LAN actif : au moins un des serveurs inclus est actif (Figure 11) ; Serveur actif mais interdisant les requêtes avec les autres serveurs (Figure 12) ; et Serveur non opérationnel (Figure 13). Les liaisons sont représentées sous forme de traits reliant les serveurs avec une animation des états 20 suivants : Liaison permettant des échanges de messages de signalisation et de données FTP (Figure 14) ; Liaison avec interruption de la signalisation (Figure 15) ; et 25 Liaison permettant les échanges de messages signalisation mais pas de données sous protocole FTP (Figure 16). Les états affichés des liaisons résultent 30 pour : - Le protocole de signalisation d'un test cyclique automatique de surveillance entre serveurs - Le protocole FTP d'un test en réel sur un fichier test réalisé au démarrage de l'application ou sur 35 demande manuelle dans le système selon l'invention. Une liste de menus contextuels est affichable en fonction de la zone pointée : Cercle serveur : accès à la visualisation des états/traces et à la configuration relative au serveur (Figure 17) ; et Zone commune hors serveur : accès à la visualisation des états/traces et à la configuration de toute l'infrastructure (Figure 18). La vue détaillée de l'environnement contrôlé par le serveur du système selon l'invention est personnalisable. Des schémas édités sous Visio (marque déposée) peuvent être importées/exportés pour représenter graphiquement les équipements contrôlés par le serveur. Lors de l'édition, l'éditeur désignera les icônes à animer en leur attribuant une adresse IP. Dans le cadre de cette implémentation, une application cliente notifie au serveur du système selon l'invention les équipements qu'elle a détectés sous les adresses paramétrées dans le schéma. Si une icône a une adresse qui ne correspond à aucun équipement, l'icône le représentant sera barrée comme ci-dessous. Pour chaque équipement détecté mais non représenté dans le schéma une icône est affichée en bas à gauche de la vue (on se référera à la Figure 9). Lors de l'export du schéma, les icônes ajoutées sont conservées, il est alors possible de modifier le schéma tout en bénéficiant des informations des équipements détectés. Ces objets graphiques sont animés pour afficher les états suivants : L'équipement est actif et tous les services embarqués contrôlés par le serveur sont opérationnels ; L'équipement est inactif ; L'équipement est actif mais un des services embarqués rapporte une anomalie. La sélection d'objets graphiques affiche la liste de menus contextuels pour afficher ou configurer les données propres à l'équipement et à ses services (on se référera à la Figure 19). La Figure 19 illustre une liste de menus contextuels par équipement. Les traces de toutes requêtes clientes et de leur état d'exécution sont affichables sous forme de liste avec les champs suivants : Command : type de requête Start time : heure/date d'émission de la 15 requête Duration : durée d'exécution en cours ou terminée Status : Etat de la requête (interprétée, analysée, allouée en attente, en exécution, terminée) 20 Owner Id : identifiant s'il est connu de l'application qui émet la requête Owner : identifiant du serveur du système selon l'invention qui a réceptionné la requête Paraml : 1û champ d'attributs de la requête 25 (Pour une demande de copie, permet de renseigner l'URL - Uniform Resource Locator - de la source à copier). Param2 : 2ème champ d'attributs de la requête (Pour une demande de copie, permet de connaître l'URL de la destination pour copier). 30 L'étendue des requêtes dépend du contexte à partir duquel le menu a été appelé : requêtes pour tout le réseau du système selon l'invention, requêtes pour lequel le serveur du système selon l'invention est 35 impliqué soit parce qu'il en est le receveur soit qu'il exécute une requête émise sur un serveur distant (on se référera à la Figure 20), requêtes impliquant les services embarqués de l'équipement considéré. La Figure 20 illustre l'affichage des requêtes 5 en attente, en cours ou terminées d'un serveur, dans le cadre du système selon la présente invention. Il est possible de trier les requêtes en sélectionnant les en-têtes de champs affichés. Une 10 première sélection permet d'activer le champ comme clé de tri dans l'ordre croissant avec un rang qui dépend des clés précédemment sélectionnées. Les sélections suivantes permettent de basculer entre l'ordre croissant et décroissant. 15 La désélection d'un champ permet de lui ôter le statut de clé de tri et les champs ayant une clé de rang inférieur remontent d'un cran. Toutes les requêtes terminées sont stockées et 20 consultable sur une profondeur de plusieurs jours à partir de la vue History . Il est possible d'afficher les traces sur une fenêtre temporelle choisie. Un affichage AsRunLog (rapport concernant 25 les requêtes FTP effectuées - représenté Figure 21) filtre l'affichage aux requêtes FTP pour recopier, renommer, détruire les données. Ce rapport peut servir de support pour traquer les données à des fins de facturation, de gestion de cycle de vie, de protection 30 La Figure 21 représente un rapport concernant les requêtes FTP effectuées ( AsRunLog ). L'administrateur peut surveiller en temps réel 35 la capacité du réseau à transporter en priorité temps réel la signalisation du système selon l'invention et des classes de services de l'application. Les métriques sous forme de rapport ou de graphique présentent : les délais des messages de signalisation pour aller/retour entre serveurs du système selon l'invention (on se référera à la Figure 22 qui représente un rapport concernant les temps aller/retour de signalisation). les tailles des messages et les débits échangés par classe de service (on se référera à la Figure 23) et le graphique des débits instantanés de la signalisation, (on se référera à la Figure 24). L'extraction des données peut être filtrée aux échanges de l'ensemble du réseau dans le système selon l'invention, des liaisons de tous les serveurs vers un seul, de la liaison d'un serveur à un autre. L'utilisateur peut choisir la fenêtre temporelle de visualisation ainsi que les ajustements d'échelles et de zoom. La Figure 23 illustre un rapport concernant la taille des messages et le débit par classe de service et la Figure 24 illustre un graphique représentant le débit de la signalisation. L'administrateur peut évaluer en temps réel 25 la qualité de la régulation de trafic à partir des indicateurs . Ecart entre demande et prévision du transfert Ecart entre prévision et réalisation du transfert 30 Variation positive comme négative du rapport entre la durée réalisée et la durée prévue du transfert. L'écart peut être négatif dans le cas où le nombre maximum de transferts permis pas la régulation de trafic n'est pas atteinte ou encore lorsque la bande passante du 35 réseau en réel est supérieure à celle définie dans le paramétrage du trafic FTP. La Figure 25 représente des indicateurs de qualité de régulation du trafic FTP. Les évènements sont consignés par les serveurs 5 du système selon l'invention dans leur fichier Event Log respectif. La consultation est centralisée pour permettre d'extraire le fichier d'événements de tout serveur du système selon l'invention à partir du poste 10 d'administration (on se référera à la Figure 26). La Figure 26 illustre le choix du serveur pour afficher un rapport concernant des événements ( EventLog ). Des contrôles de gestion permettent d'améliorer la navigabilité à l'intérieur de 1'Event Log • La liste à gauche des événements en vis à vis de la description détaillée à droite de l'événement pointé • Une liste des occurrences passées du même type d'événement que celui qui est pointé pour permettre par double clic de s'y déplacer directement. 25 Une aide au diagnostique (on se référera à la Figure 27) est affichée sous la description de l'événement pour apporter des informations sur les possibles causes et leurs remèdes connus. Cette aide peut 30 être enrichie indépendamment des livraisons de logiciels car elle est contenue dans un fichier interprété. La Figure 27 représente un rapport concernant des événements ( EventLog ) ainsi qu'une fenêtre d'aide 35 au diagnostic. Les versions logicielles du serveur dans le cadre du système selon l'invention peuvent être: 15 20 • déployées localement, ce qui nécessite d'intervenir sur chaque site * chargées sur un serveur du système selon l'invention pour être déployées sur d'autres serveurs distants. Le déploiement local nécessite le lancement d'un script qui automatise toutes les étapes. Chaque étape vérifie que les conditions d'entrée sont réunies et suspend le script en affichant la correction à apporter pour en reprendre son exécution. La Figure 28 illustre un script d'installation du système selon la présente invention avec un message 15 d'avertissement. La dernière étape pour finaliser une installation en local est la saisie ou vérification/modification de la clé d'authentification du 20 serveur du système selon l'invention. La clé présentée par un serveur Multi Site doit être identique à celle des autres serveurs pour lui permettre d'intégrer leur réseau. La clé d'authentification est stockée dans un 25 répertoire appelé Active Directory lors de la première installation du premier serveur du domaine Windows (marque déposée). Lors d'installations locales de mises à jour du serveur du système selon l'invention ou de première 30 installation d'autres serveurs dans ce domaine, elle sera affichée pour éventuelle modification. Elle sera aussi modifiable depuis le poste d'administration. 35 La Figure 29 illustre un masque de saisie de la clé d'authentification lors de l'installation. Le déploiement à distance est programmable à partir du poste d'administration (on se référera à la Figure 30). Une fois la mise à jour chargée sur le serveur du système selon l'invention auquel le poste est connecté, l'administrateur la sélectionne parmi les versions déjà chargées puis programme la date et heure de déploiement qui sera identique pour tous les serveurs. Si l'administrateur a un rôle d'administrateur de domaine, la programmation de serveurs du système selon l'invention de son domaine sera automatiquement validée. Par contre, la programmation est soumise à la validation des administrateurs des autres serveurs du système selon l'invention qui peuvent l'approuver sans modification, l'approuver en la différant, voir l'annuler. Toutes les décisions éventuellement commentées sont retournées à l'administrateur qui a programmé le déploiement pour lui permettre d'agir en conséquence. La Figure 30 représente la programmation de 20 déploiement à distance du système selon la présente invention. L'invention est décrite dans ce qui précède à titre d'exemple. Il est entendu que l'homme du métier est 25 à même de réaliser différentes variantes de l'invention sans pour autant sortir du cadre du brevet. REVENDICATIONS 1. Système d'informations pour un environnement de diffusion audio/vidéo ( broadcast ), comportant au moins deux serveurs reliés entre eux par un réseau de communication, des applications clientes informatiques se connectant aux dits serveurs, caractérisé en ce qu'il comprend : • des moyens pour accéder depuis un serveur à des données contrôlées par un autre serveur ; • des moyens pour échanger des messages entre serveurs ; • des moyens pour échanger des données entre des applications s'exécutant sur différents serveurs ; et • des moyens de visualisation d'indicateurs liés aux ressources du réseau et des serveurs. 2. Système d'informations selon la revendication 1 caractérisé en ce qu'au moins un des indicateurs porte sur le temps de réponse du réseau. 3. Système d'informations selon la revendication 1 ou 2 caractérisé en ce qu'au moins un des indicateurs porte sur le délai de réception de données par les applications informatiques. 4. Système d'informations selon la revendication 1, 2 ou 3 caractérisé en ce que les échanges de données s'effectuent selon le protocole FTP (File Transfer Protocol). 35 5. Système d'informations selon l'une au moins des revendications précédentes caractérisé en ce que les 15 20 25 30échanges de messages sont réalisés au moyen du protocole Message Queuing de la société Microsoft (marque déposée). 6. Système d'informations selon l'une au moins des revendications précédentes caractérisé en ce que les données à échanger sont réparties en deux flux : • la signalisation qui inclut des ordres de transfert de données, des messages techniques propres au système et des classes de services des applications informatiques ; et • les transferts de données pour transporter les données en mode fichier ou en mode flux. 7. Système d'informations selon l'une au moins des revendications précédentes caractérisé en ce qu'il comporte des moyens d'observation en temps réel des serveurs et du réseau. 8. Système d'informations selon la revendication précédente caractérisé en ce que ladite observation est matérialisée sous la forme de représentation graphique ou de rapports. 9. Système d'information selon la revendication 4 caractérisé en ce qu'il comporte des moyens pour modéliser des ressources du réseau afin de réguler le trafic FTP. 30 10. Système d'informations selon la revendication 4 ou 9 caractérisé en ce qu'il comporte des moyens pour centraliser l'intégralité du trafic FTP afin d'effectuer une reprise en mode manuel de la 35 planification. 25 5 10 15 11. Système d'informations selon l'une au moins des revendications précédentes caractérisé en ce qu'il comprend des moyens pour modéliser les ressources réseau sollicitées par les échanges de fichiers de données. 12. Système d'informations selon l'une au moins des revendications précédentes caractérisé en ce qu'il comprend des moyens pour contrôler ou planifier automatiquement le trafic. 13. Système d'informations selon l'une au moins des revendications précédentes caractérisé en ce qu'il comprend des moyens pour visualiser et permettre la reprise manuelle de la planification du trafic. 20