FR 2925722 A1 20090626 FR 0708952 A 20071220 RÉSEAU INFORMATIQUE DOTÉ D'UN ARCHIVAGE AUTOMATIQUE DE FICHIERS L'invention concerne un réseau informatique doté de fonctions avancées d'archivage automatique de fichiers. Dans tout le texte, le terme � fichiers � désigne des fichiers tels que mémorisés en mémoire de masse et susceptibles d'être gérés comme tels par au moins un système d'exploitation et de gestion de fichiers (�OS�) de dispositif informatique. Un fichier est désigné par un identificateur unique (nom du fichier) permettant d'accéder aux données de ce fichier mémorisées en mémoire de masse. Un fichier inclut un ensemble de données utiles pour au moins un dispositif informatique et/ou au moins un utilisateur, constituant un contenu de ce fichier. Sauf indication contraire, le terme � données � utilisé en référence à un fichier, désigne des données de contenu d'un fichier. L'archivage de fichiers vise pour l'essentiel à mémoriser en mémoire de masse spécifique les données de contenu de fichiers. Par ailleurs, de façon connue en soi, certaines données, dites métadonnées, sont descriptives de fichiers, de certaines de ses propriétés et/ou de tout ou partie de son contenu. Les métadonnées de fichiers peuvent être une partie du contenu de ce dernier, tout ou partie du contenu d'un autre fichier, ou générées de façon dynamique par un traitement logiciel -notamment par un système d'exploitation- à partir du fichier considéré. De façon générale, l'invention concerne un réseau informatique comprenant : - au moins un serveur de fichiers, dit serveur source, 25 doté d'au moins un agent de collecte de fichiers à archiver, û au moins un serveur d'archivage adapté pour permettre l'archivage de fichiers sur au moins une mémoire de masse associée à ce serveur d'archivage, û et au moins une liaison numérique de réseau adaptée pour permettre l'échange d'informations numériques entre les serveurs. On connaît déjà (cf. par exemple US 2004/0236801) de tels réseaux informatiques dans lesquels : û le serveur d'archivage est doté d'au moins un agent de gestion d'archivage adapté pour pouvoir émettre une commande de déclenchement de collecte à destination d'un agent de collecte d'un serveur source, cette commande de déclenchement incorporant des données représentatives de critères de collecte prédéterminés, - ledit agent de collecte est adapté pour exécuter sur le serveur source une recherche de fichiers correspondant aux critères de collecte d'une commande reçue de l'agent de gestion d'archivage. Ces réseaux informatiques, et les systèmes d'archivage connus qu'ils comprennent, présentent plusieurs séries d'inconvénients. Tout d'abord, ils nécessitent l'établissement d'une liaison numérique performante, c'est-à-dire de bande passante élevée, entre chaque serveur source et le serveur d'archivage pour le transfert des fichiers. Or, le développement des réseaux informatiques modernes implique d'optimiser au maximum la bande passante des liaisons numériques, en affectant au maximum cette bande passante à la transmission de données utiles aux différents utilisateurs du réseau. En particulier, il est à noter que ces systèmes connus nécessitent de nombreux transferts de données qui, en réalité, ne sont pas strictement nécessaires pour l'archivage de fichiers. En effet, par exemple, un même ensemble de données représentant un contenu de fichier peut être dupliqué sur différents serveurs source, voire même sur un même serveur source. Dans ce cas, les différents fichiers correspondants sont systématiquement archivés par les systèmes connus indépendamment de leur contexte. Il est aussi à noter à ce titre que l'archivage des fichiers est considéré essentiellement, du point de vue d'un utilisateur, comme une tâche d'administration secondaire du système informatique. Par ailleurs, dans le même sens, il est important de veiller à ce que l'agent de collecte n'occupe qu'un minimum des ressources informatiques du serveur source, de façon à ne pas en perturber le fonctionnement, et à laisser le maximum de ces ressources disponibles pour l'utilisateur de ce serveur source. Également, les réseaux informatiques modernes sont de plus en plus hétérogènes, et permettent la communication de stations de travail très diverses aussi bien en ce qui concerne le format des fichiers contenus, que les systèmes d'exploitation et de gestion de fichiers. Le système d'archivage de fichiers sur le réseau doit donc être compatible avec ces différents formats et systèmes d'exploitation. Or, la plupart des systèmes d'archivage connus sont au contraire étroitement dépendants du système d'exploitation et de gestion des fichiers, et ne sont pas compatibles avec d'autres systèmes de gestion de fichiers. Par exemple, les systèmes d'archivage connus compatibles avec le système d'exploitation Windows� ne sont en général pas compatibles avec le système d'exploitation Linux� ou Unix�. Ce problème se pose de façon d'autant plus accru avec le développement des fichiers auxquels sont associées des métadonnées, qui sont des données décrivant le contenu du fichier et/ou des propriétés informatiques du fichier et/ou d'autres informations associées aux fichiers et utiles à l'utilisateur et/ou aux applications logicielles susceptibles de travailler sur ce fichier. À ce titre, les inventeurs ont déterminé qu'un système 20 d'archivage réseau performant devrait être compatible avec : ù les différentes catégories de métadonnées pouvant être rencontrées, et les différents formats dans lesquels ces métadonnées peuvent être enregistrées, ù tout système d'information doté d'au moins un serveur de fichiers, et ce, indépendamment des applications logicielles qui gèrent et traitent l'information 25 et le contenu des données (par exemple les applications de gestion électronique de documentations ou documents), ù l'archivage de données non structurées en association avec des métadonnées collectées et/ou enrichies par le serveur d'archivage, de façon notamment à offrir ultérieurement la possibilité d'effectuer des recherches L contextuelles sur l'information archivée et/ou de présenter l'information restaurée en fonction du contexte. L'invention vise à proposer une solution à ces problèmes. En conséquence, l'invention vise en particulier à proposer un réseau informatique doté d'un système d'archivage qui, d'une part, soit compatible avec une faible bande passante dans la liaison numérique entre chaque serveur d'archivage et chaque serveur source, et/ou qui, en tout état de cause, n'occupe qu'une faible partie de cette bande passante ; évite la multiplication des transferts d'ensembles de données identiques dupliqués sur différents fichiers source, mais permette cependant l'archivage de métadonnées associées à chacun de ces fichiers source ; d'autre part, n'utilise qu'une très faible partie des ressources informatiques de chaque serveur source et soit extrêmement peu perturbateur du fonctionnement de chaque serveur source ; par ailleurs, soit compatible avec des architectures informatiques et des applications logicielles très diverses ; permette l'acquisition et/ou la création et/ou l'association, aux données et fichiers archivés, de métadonnées diverses, notamment de métadonnées permettant une gestion contextuelle des informations archivées ; permette une gestion dynamique et automatique, évolutive dans le temps, de chaque serveur d'archivage. Pour ce faire, l'invention concerne un réseau informatique 20 comprenant : ù au moins un serveur de fichiers, dit serveur source, doté d'un agent de collecte de fichiers à archiver, ù au moins un serveur d'archivage adapté pour permettre l'archivage de fichiers sur au moins une mémoire de masse associée à ce serveur 25 d'archivage, et doté d'un module de gestion d'archivage, ù et au moins une liaison numérique de réseau adaptée pour permettre l'échange d'informations numériques entre les serveurs, dans lequel : ù ledit module de gestion d'archivage est adapté pour pouvoir émettre une commande de collecte à destination d'au moins un agent de collecte d'au moins un serveur source, cette commande de collecte incorporant des données représentatives de critères de collecte prédéterminés -comprenant notamment des données identifiant au moins un instant de déclenchement de la collecte et/ou au moins une fenêtre temporelle de réalisation de la collecte par ledit agent de collecte-, ledit agent de collecte étant adapté pour exécuter sur le serveur source une recherche de fichiers correspondant aux critères de collecte d'une commande reçue par ledit agent de collecte et émise par l'agent de gestion d'archivage, caractérisé en ce que, pour chaque fichier collecté par ledit agent de collecte, ce dernier est adapté pour : û calculer, à partir de données contenues dans le fichier collecté et enregistrées sur le serveur source (c'est-à-dire sur au moins une mémoire de masse de ce dernier), et selon un procédé de calcul unique prédéterminé, un code numérique, dit code calculé, comprenant au moins un nombre, dit code identifiant, dont la valeur dépend uniquement des dites données et dudit procédé de calcul et est propre aux dites données, û transmettre le code calculé au module de gestion d'archivage, en ce que le serveur d'archivage est adapté pour pouvoir, à réception d'un code calculé, rechercher s'il existe, en mémoire de masse du serveur d'archivage, des données correspondant à ce code calculé -notamment au moins un enregistrement contenant ce code calculé et/ou le code identifiant-, en ce qu'il est adapté pour réaliser un transfert au serveur d'archivage des dites données du serveur source contenues dans le fichier collecté et correspondant au code calculé, si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que des données correspondant au code calculé ne sont pas présentes en mémoire de masse du serveur d'archivage, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces données contenues dans le fichier collecté et le code calculé associé à ces données, et en ce qu'il est adapté pour ne pas transférer au serveur d'archivage lesdites données du serveur source contenues dans le fichier collecté et correspondant au code calculé, si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que des données correspondant au code calculé sont présentes en mémoire de masse du serveur d'archivage. Avantageusement et selon l'invention, ledit module de gestion d'archivage est adapté pour pouvoir transmettre à l'agent de collecte des données numériques représentatives du résultat de ladite recherche de données mémorisées en mémoire de masse du serveur d'archivage et correspondant au code calculé, et en ce que ledit agent de collecte est adapté pour : ù si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que des données correspondant au code calculé ne sont pas présentes en mémoire de masse du serveur d'archivage, générer une commande d'autorisation de transfert au serveur d'archivage des données du serveur source contenues dans le fichier collecté, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces données contenues dans le fichier collecté et ce code calculé associé à ces données, si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que des données correspondant au code calculé son présentes en mémoire de masse du serveur d'archivage, ne pas générer une commande d'autorisation de transfert des données contenues dans le fichier collecté. Par ailleurs, avantageusement et selon l'invention, le module de gestion d'archivage est adapté pour réaliser ladite recherche en recherchant s'il existe, en mémoire de masse du serveur d'archivage, au moins un enregistrement contenant le code identifiant. Plus particulièrement, avantageusement, un réseau selon l'invention est adapté pour : si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que le code identifiant n'est pas présent en mémoire de masse du serveur d'archivage, générer une commande de transfert au serveur d'archivage des données du serveur source contenues dans le fichier collecté, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces données contenues dans le fichier collecté et ce code identifiant associé à ces données, ù si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que le code identifiant est présent en mémoire de masse du serveur d'archivage, ne pas générer une commande de transfert des données contenues dans le fichier collecté. Avantageusement et selon l'invention, le code calculé, et notamment le code identifiant, est calculé à partir des données du fichier collecté autres que des métadonnées de ce fichier collecté. En particulier, la valeur du code identifiant dépend uniquement des données du fichier collecté autres que des métadonnées de ce fichier collecté, et est représentatif uniquement des données de contenu du fichier collecté, mais non des métadonnées de ce fichier collecté. En outre, avantageusement et selon l'invention, pour chaque fichier collecté, l'agent de collecte de fichiers est adapté pour collecter des métadonnées associées à ce fichier et, si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que des données correspondant au code calculé sont présentes en mémoire de masse du serveur d'archivage, générer une commande d'autorisation de transfert partiel adaptée pour autoriser uniquement le transfert de tout ou partie de ces métadonnées au module de gestion d'archivage, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces métadonnées en association avec les données du fichier collecté. Ainsi, dans un réseau selon l'invention, les métadonnées associées à un fichier collecté sont transmises quel que soit le résultat de ladite recherche effectuée par le module de gestion d'archivage en ce qui concerne le code calculé. Il est à noter par ailleurs que la valeur du code calculé, et en particulier la valeur du code identifiant, ne dépend pas des métadonnées associées au fichier collecté, ces métadonnées, qu'elles soient ou non contenues dans le fichier collecté, n'étant pas utilisées dans le procédé de calcul du code calculé, en particulier dans le procédé de calcul du code identifiant. Par ailleurs, avantageusement et selon l'invention, pour chaque fichier collecté, l'agent de collecte de fichiers est adapté pour collecter et associer à ce fichier collecté, des métadonnées résultant de données et/ou métadonnées enregistrées sur le serveur source concerné. En particulier, il s'agit de métadonnées collectées sur le serveur source autres que des métadonnées techniques. Avantageusement et selon l'invention, pour chaque fichier collecté, l'agent de collecte de fichiers est adapté pour collecter et associer à ce fichier collecté, des métadonnées choisies parmi : û des métadonnées techniques MDT décrivant tout ou partie du contenu technique du fichier lui-même et associées à ce fichier ; û des métadonnées élaborées par une application logicielle distincte et enregistrées selon une structure prédéterminée, par exemple des métadonnées d'en-tête et/ou des métadonnées enregistrées dans une base de données et/ou de métadonnées enregistrées dans un fichier distinct (par exemple des métadonnées relatives à un style ou un format...) ; û des métadonnées générées selon au moins un traitement informatique prédéterminé par l'agent de collecte, par exemple : • des métadonnées contextuelles générées à partir de données représentant la position du fichier collecté dans le système de gestion de fichiers du serveur source, et/ou l'environnement informatique de ce fichier collecté dans le système de gestion de fichiers du serveur source, et/ou des attributs du fichier collecté et/ou, • des métadonnées statiques correspondant à une ou plusieurs valeurs saisies par l'utilisateur, à exemple lors de la configuration de la collecte, • des métadonnées calculées obtenues par un calcul simple à partir des données du fichier collecté, par exemple par un calcul d'indexation simple. L'utilisation de telles métadonnées dans un réseau selon l'invention, enregistrées dans le serveur d'archivage en association avec les données d'un fichier collecté procure de nombreux avantages. En particulier, ces métadonnées peuvent faire l'objet ultérieurement d'analyses, de croisements et de déductions logiques. Plus généralement, l'archivage ainsi réalisé devient dynamique en ce sens qu'il est susceptible d'évoluer dans le temps. Les données et métadonnées enregistrées dans le serveur d'archivage peuvent être indexées, immédiatement à chaque enregistrement, ou en différé. Des procédés d'indexation peuvent être à tout moment ajoutés, en fonction des besoins, dans un serveur d'archivage selon l'invention. En outre, il est possible d'utiliser des outils d'optimisation de l'enregistrement des données, et en particulier pour l'optimisation des ressources des mémoires de masse du serveur d'archivage, en fonction de cycles de vie des données et/ou des métadonnées associées, de plans de stockage des données (en fonction par exemple des durées de conservation des données ; des migrations et conversions de format, notamment selon les évolutions logicielles ; des stratégies de destruction des données...). Dans un réseau selon l'invention, il est même possible de piloter intégralement le serveur d'archivage à l'aide des différentes métadonnées associées aux fichiers archivés. Il est à noter à ce titre que ce pilotage du serveur d'archivage peut être réalisé de façon automatique par une application logicielle en fonction des métadonnées, sans aucune intervention d'un opérateur. Par ailleurs, il est possible d'intégrer des moteurs de recherches avancées utilisant les différentes métadonnées et/ou des résultats d'indexation pour faciliter ultérieurement la recherche et/ou la présentation contextuelle des données archivées. Par ailleurs, avantageusement et selon l'invention, pour chaque fichier collecté et transféré au serveur d'archivage avec au moins un code calculé, ledit module de gestion d'archivage est adapté : ù pour calculer un code de vérification, à partir des données contenues dans le fichier collecté telles que reçues par le serveur 9 d'archivage et selon ledit procédé de calcul unique prédéterminé utilisé par l'agent de collecte pour calculer ledit code identifiant correspondant, û pour comparer la valeur de ce code de vérification calculée à partir des données reçues, avec la valeur de ce code identifiant transmise avec lesdites données du fichier collecté, û et pour mémoriser en mémoire de masse les données contenues dans le fichier collecté (de préférence avec le code calculé, ou en tout cas au moins le code identifiant) si et seulement si ces deux valeurs du code de vérification et du code identifiant sont égales. Ainsi, ledit code calculé, et plus particulièrement le code identifiant, est utilisé pour vérifier l'intégrité des données de chaque fichier collecté après chaque transfert vers le serveur d'archivage. Également, ce même code calculé, et plus particulièrement le code identifiant, peut être utilisé pour vérifier l'intégrité des données transférées en cas de restauration d'un fichier, c'est-à-dire de transfert depuis le serveur d'archivage vers un serveur source. Par ailleurs, selon un mode de réalisation avantageux, le module de gestion d'archivage comprend un module de gestion de collecte adapté pour centraliser les communications entre le module de gestion d'archivage et chaque agent de collecte. De préférence, le module de gestion de collecte comprend un module de transfert de fichiers adapté pour contrôler le transfert des données de chaque fichier collecté entre un serveur source et le serveur d'archivage. Il est à noter que dans un réseau selon l'invention, les données d'un même fichier peuvent être enregistrées en mémoire de masse d'un seul serveur source et transférées alors entièrement en mode � point-à-point � traditionnel, c'est-à-dire par exemple par un transfert de type FTP, ou au contraire dupliquées sur divers serveurs source (par exemple formés de stations de travail utilisateurs). Dans ce dernier cas, le code calculé permet d'éviter de transférer plusieurs fois le même fichier vers le serveur d'archivage à partir de plusieurs serveurs source. En outre, avantageusement et selon l'invention, le module de transfert de fichiers est adapté pour limiter le nombre de transferts simultanés vers le serveur d'archivage et/ou le taux de transfert des données à une valeur seuil maximum prédéterminée. L'invention concerne également un réseau caractérisé en combinaison par tout ou partie des caractéristiques mentionnées ci-dessus ou ci-après. D'autres buts, caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante de ses modes de réalisation préférentiels, donnée uniquement à titre d'exemple non illustratif et qui se réfère aux figures annexées dans lesquelles : la figure 1 est un schéma synoptique d'un réseau informatique selon l'invention, û la figure 2 est un organigramme schématique représentant un mode de réalisation des principales étapes réalisées par un agent de collecte dans un réseau selon l'invention pour l'initialisation d'une collecte, û la figure 3 est un schéma synoptique illustrant un exemple de dialogue entre un agent de collecte et un module de gestion d'archivage d'un réseau selon l'invention pour l'initialisation d'une collecte, la figure 4 est un organigramme schématique représentant un mode de réalisation 20 des principales étapes réalisées par un agent de collecte dans un réseau selon l'invention lors d'une étape de collecte, la figure 5 est un schéma synoptique illustrant un exemple de dialogue entre un agent de collecte et un module de gestion d'archivage d'un réseau selon l'invention lors d'une étape de collecte, 25 la figure 6 est un schéma d'un exemple de fichier illustrant sa constitution (données et métadonnées) et les métadonnées pouvant être associées aux données de ce fichier dans le serveur d'archivage d'un réseau selon l'invention, la figure 7 est un organigramme schématique représentant un exemple de réalisation d'étapes réalisées par un module de vérification du code calculé dans un réseau selon l'invention. L'organisation générale d'un réseau informatique selon l'invention est représentée schématiquement figure 1. Le réseau comprend tout d'abord un système 1 de liaisons de communication adaptées pour permettre l'échange de données et informations numériques, c'est-à-dire formant un réseau numérique. Ce système 1 de liaisons peut présenter une architecture quelconque, incorporer ou non des liaisons spécifiques point-à-point, des accès à un ou plusieurs réseau(x) public(s) tel que le réseau Internet, des accès à un ou plusieurs réseau(x) informatique(s) privé(s)... Par ailleurs, l'invention est compatible avec toute(s) technologie(s) de réalisation d'un tel système 1 de liaisons (filaires, radiofréquences, par satellites, via un réseau de téléphonie mobile...). Au moins un serveur de fichiers, dit serveur source 2 est relié à ce système 1 de liaisons. Un tel serveur source 2 est un système informatique comprenant au moins une unité centrale dotée d'une capacité de traitement de données numériques à microprocesseur(s) et mémoire(s) vive(s) associée(s), et au moins un système d'exploitation OS, c'est-à-dire un ensemble logiciel adapté pour réaliser des fonctions d'administration et de gestion de fonctionnement du système informatique, et en particulier des fonctions de gestion de fichiers enregistrés sur au moins une mémoire de masse 3, 4 associée (par le système d'exploitation OS) à ce serveur source 2. Une telle mémoire de masse peut-être une mémoire de masse 3 reliée localement au serveur source 2, (par exemple un ou plusieurs disque(s) dur(s) magnétique(s) et/ou électronique(s) et/ou optique(s), interne(s) ou externe(s), ou autre). La mémoire de masse associée au serveur source 2 peut comprendre une mémoire de masse 4 de type réseau, c'est-à-dire directement reliée au système 1 de liaisons, le serveur source 2 accédant à cette mémoire de masse 4 via le système 1 de liaisons. Une telle mémoire de masse 4 réseau peut également comporter un ou plusieurs disque(s) dur(s) magnétique(s) et/ou électronique(s) et/ou optique(s), et/ou une ou plusieurs unité(s) regroupant plusieurs disques durs (par exemple de type RAID) ou toute autre mémoire de masse 4 susceptible d'être reliée de façon autonome à un réseau. Bien sûr, plusieurs mémoires de masse 3, 4 distinctes peuvent être associées au même serveur source 2. Un serveur source 2 au sens de la présente invention peut être constitué de tout système informatique connu, non seulement du type micro- ordinateur personnel, fixe, portable ou portatif, mais également par exemple du type assistant personnel numérique, téléphone numérique portatif, ou au contraire de type centre de calcul ou autre. Par ailleurs, le réseau selon l'invention comprend également au moins un serveur d'archivage 5 relié audit système 1 de liaisons. Un tel serveur d'archivage 5 est un système informatique comprenant au moins une unité centrale dotée d'une capacité de traitement de données numériques à microprocesseur(s) et mémoire(s) vive(s) associée(s), et au moins un système d'exploitation (non représenté figure 1), c'est-à-dire un ensemble logiciel adapté pour réaliser des fonctions d'administration et de gestion de fonctionnement du système informatique, et en particulier des fonctions de gestion de fichiers enregistrés sur au moins une mémoire de masse 6, 7 associée (par le système d'exploitation) à ce serveur d'archivage 5. Une telle mémoire de masse peut-être une mémoire de masse 6 reliée localement au serveur d'archivage 5, (par exemple un ou plusieurs disque(s) dur(s) magnétique(s) et/ou électronique(s) et/ou optique(s), interne(s) ou externe(s), ou autre). La mémoire de masse associée au serveur d'archivage 5 peut comprendre une mémoire de masse 7 de type réseau, c'est-à-dire directement reliée au système 1 de liaisons, le serveur d'archivage 5 accédant à cette mémoire de masse 7 via le système 1 de liaisons. Une telle mémoire de masse 7 réseau peut également comporter un ou plusieurs disque(s) dur(s) magnétique(s) et/ou électronique(s) et/ou optique(s), et/ou une ou plusieurs unité(s) regroupant plusieurs disques durs (par exemple de type RAID) ou toute autre mémoire de masse 7 susceptible d'être reliée de façon autonome à un réseau. Bien sûr, plusieurs mémoires de masse 6, 7 distinctes peuvent être associées au même serveur d'archivage 5. Chaque serveur source 2 comprend un agent de collecte 8 de fichiers à archiver, qui est adapté pour exécuter sur le serveur source 2 une recherche de fichiers correspondant à des critères de collecte d'une commande de collecte reçue par cet agent de collecte 8 via le système 1 de liaisons depuis le serveur d'archivage 5. Le serveur d'archivage 5 est quant à lui doté d'un module de gestion d'archivage 9 qui est adapté pour permettre la définition et l'enregistrement d'une commande de collecte incorporant des données représentatives de critères de collecte prédéterminés, et pour pouvoir émettre une telle commande de collecte sur le système 1 de liaisons à destination d'au moins un agent de collecte 8 d'au moins un serveur source 2. Le module de gestion d'archivage 9 du serveur d'archivage 5 comprend un module de gestion de collecte 10 qui est le seul point d'accès au serveur d'archivage 5 par les agents de collecte 8 des différents serveurs source 2. En outre, le module de gestion de collecte 10 est adapté pour permettre à un utilisateur de définir une commande de collecte, c'est-à-dire de saisir des critères de collecte prédéterminés. Par exemple, les critères de collecte d'une commande de collecte peuvent être choisis parmi : û le (ou les) serveur(s) source 2 concerné(s) par la collecte, û la date et l'heure du premier lancement de la collecte sur chaque serveur source 2, û chaque période de temps (fenêtre temporelle définie par une date et une heure de début et une date et une heure de fin, ces dates et heures pouvant être définies de façon absolue ou au contraire de façon relative par rapport à des événements prédéterminés tels que l'allumage d'un serveur, l'extinction d'un serveur, une périodicité...) au cours de laquelle la collecte est autorisée à s'exécuter, û des critères portant sur tout ou partie du chemin d'accès des fichiers concernés par la collecte, û des critères d'incorporation et/ou d'exclusion des fichiers dans la collecte, notamment en fonction de métadonnées techniques (type de fichier, taille du fichier, auteur, propriétaire, date de création, date de modification, date du dernier accès,...) et/ou de métadonnées d'en-tête du fichier et/ou de données d'indexation... Le module de gestion de collecte 10 du module de gestion d'archivage 9 est par ailleurs adapté pour émettre à destination de chaque serveur source 2 concerné sur le système 1 de liaisons, une commande de déclenchement de la collecte correspondante. Le déclenchement d'une collecte par un agent de collecte 8 10 peut être commandé par le module de gestion de collecte 9 selon différents critères qui sont par exemple choisis parmi : û des propriétés temporelles (date fixe, périodicité journalière, hebdomadaire, mensuelle, annuelle,...), û des commandes de déclenchement externes telles que 15 des interventions manuelles d'un administrateur, ou une commande en provenance d'une application logicielle spécifique du serveur d'archivage 5 ou externe à ce serveur d'archivage 5 (via le système 1 de liaisons)... Chaque agent de collecte 8 est préalablement configuré de façon à ce que l'adresse du serveur d'archivage 5 qui lui était associé lui soit connue 20 (cette adresse étant enregistrée sur le serveur source 2). Ainsi, dans un réseau selon l'invention, les agents de collecte 8 des différents serveurs source 2 ne sont pas autonomes, mais au contraire entièrement sous le contrôle du module de gestion d'archivage 9 d'un serveur d'archivage. Autrement dit, le fonctionnement du module de gestion d'archivage 9 et 25 des agents de collecte 8 est du type maître/esclave, le module de gestion d'archivage 9 constituant un maître apte à contrôler le fonctionnement des agents de collecte 8, et les agents de collecte 8 ayant un fonctionnement en esclave commandé à distance via le système 1 de liaisons par le module de gestion d'archivage 9. Ce type de fonctionnement apparaît en particulier sur les figures 2 et 3. Après une étape 20 de démarrage suivie d'une étape 21 d'initialisation des collectes, l'agent de collecte 8 se place sur une étape de test 22 d'arrêt dans laquelle il est examiné si l'agent de collecte 8 doit être arrêté ou non, c'est à dire s'il a reçu ou non un signal de commande d'arrêt de la part du module de gestion d'archivage 9. Dans l'affirmative, une étape d'arrêt 23 de l'agent de collecte 8 est exécutée. Dans la négative, deux processus sont exécutés en parallèle. Dans un premier processus 24, 25 de configuration des collectes actives, la première étape 24 examine si un message 33 est reçu du module de gestion d'archivage 9. Ce message 33 peut être un signal d'arrêt d'une collecte en cours et/ou de désactivation d'une collecte déjà active, un signal d'activation d'une nouvelle collecte ou un signal de modification d'une collecte active. Si un tel message 33 est reçu, une étape 25 de configuration de collecte est ensuite exécutée, dans laquelle des données représentatives de la définition de collecte 34 sont reçues du serveur d'archivage 5 si cette étape 25 correspond à une nouvelle collecte à configurer ou à une modification de collecte active. Ensuite, les paramètres de la collecte active correspondante sont créés ou modifiés. Ensuite, l'agent de collecte 8 retourne à l'étape 22. Si aucun message 33 n'est reçu à l'étape 24, l'étape 25 n'est pas 20 effectuée. Le deuxième processus 26, 27 d'exécution des collectes effectué en parallèle permet d'exécuter les différentes collectes actives configurées par le premier processus 24, 25. Ce processus 26, 27 d'exécution des collectes comprend une première étape lors de laquelle il est examiné si une collecte active 25 doit être démarrée ou non. Par exemple, lors de l'étape 26, un instant de début de collecte prédéterminé et enregistré dans les données de définition de la collecte 34 peut être comparé à la date et à l'heure du système en cours. Si l'instant de début de collecte est atteint, cette collecte est lancée lors de l'étape 27. À défaut, l'agent de collecte 8 retourne à l'étape 22 de test d'arrêt. 16 Ainsi, dans un réseau selon l'invention, les processus de configuration des collectes et d'exécution de collecte s'exécutent de façon concurrente. De la sorte, plusieurs collectes peuvent être activées en parallèle, ainsi que la configuration de nouvelles collectes. Une fois activée, une collecte reste active sauf si cette collecte a été programmée pour n'être exécutée qu'une seule fois, ou si le module de gestion d'archivage 9 émet un signal d'interruption de cette collecte. Comme on le voit sur la figure 3, lorsque le module de gestion de collecte 10 du module de gestion d'archivage 9 détermine qu'une commande de collecte doit être adressée à un agent de collecte 8 sur un serveur source 2, il émet une requête de connexion 31 sur le réseau, c'est-à-dire à destination du serveur source 2 via le système 1 de liaisons. Dans l'hypothèse où une connexion peut être établie, l'agent de collecte 8 émet un signal 32 d'acquittement validant l'établissement de la connexion, à destination du serveur d'archivage 5. Simultanément, l'étape de démarrage 20 de l'agent de collecte 8 est effectuée comme mentionné ci-dessus. Le module de gestion de collecte 10 du module de gestion d'archivage 9 adresse ensuite une commande 33 de déclenchement et d'identification de collecte permettant de déclencher la réalisation d'une nouvelle collecte par l'agent de collecte 8 comme mentionné ci-dessus, cette commande 33 étant traitée par le test 24. Le module de gestion de collecte 10 du module de gestion d'archivage 9 du serveur d'archivage 5 adresse ensuite au serveur source 2 l'ensemble des données représentatives de la définition de la collecte 34 à effectuer, qui permettent la configuration 25 de la collecte par l'agent de collecte 8 comme décrit ci-dessus. Lorsque la collecte est terminée, l'agent de collecte 8 adresse un signal de fin de collecte 35 au module de gestion de collecte 10 du serveur d'archivage 5. La figure 4 illustre les principales étapes effectuées par l'agent de collecte 8 au cours d'une étape de collecte 27. La figure 5 illustre les échanges intervenant entre l'agent de collecte 8 et le module de gestion d'archivage 9 du serveur d'archivage 5 au cours de cette étape de collecte 27. L'étape 40 correspond au démarrage de la collecte. Au cours du test 41 subséquent, l'agent de collecte 8 exécute un module de collecte 13 qui parcourt le système de fichiers du serveur source 2 en tant que tâche de fond de ce serveur source 2. Si aucun nouveau fichier à archiver n'est détecté, un signal d'arrêt de la collecte est émis lors de l'étape 42, ce qui permet de commander le test 29 décrit ci-dessus déclenchant la fin de la collecte. Si un nouveau fichier à archiver est détecté, le test 43 examine si ce fichier est éligible pour la collecte compte tenu des paramètres de collecte reçus dans la définition de collecte 34. Si le fichier n'est pas éligible pour cette collecte, le processus retourne au test 41 pour détecter un nouveau fichier. Si le fichier est éligible, une étape 44 est exécutée lors de laquelle un code numérique, dit code calculé, est calculé à partir des données contenues dans le fichier telles que mémorisées sur la mémoire de masse 3 et/ou 4 correspondante du serveur source 2. Ce code calculé comprend au moins un nombre, dit code identifiant, dont la valeur dépend uniquement de ces données et d'un procédé de calcul prédéterminé exécuté par un module de calcul 12 de l'agent de collecte 8. La valeur du code identifiant ne dépend pas en particulier des métadonnées pouvant être associées au fichier collecté, les données du fichier correspondant à son contenu, c'est-à-dire les données autres que des métadonnées, étant extraites du fichier pour procéder au calcul du code identifiant, ou plus généralement au calcul de chaque nombre correspondant au code calculé. Le procédé de calcul utilisé lors de cette étape 44 peut être quelconque, dès lors qu'il permet d'identifier de façon biunivoque le contenu des données, dites données de contenu, du fichier qui ne sont pas des métadonnées. Autrement dit, si la valeur des données de contenu varie, le code calculé, et en particulier le code identifiant, doit varier. Au contraire, si toutes les données de contenu restent les mêmes, deux calculs successifs effectués avec le même procédé de calcul doit fournir la même valeur pour le code calculé, et en particulier pour le code identifiant. Dans un exemple de réalisation, le code calculé comprend : une valeur numérique indiquant la taille totale des données de contenu mémorisées en mémoire de masse ; un code intermédiaire qui est le résultat d'un premier calcul de vérification effectué sur les données de contenu , par exemple du type calcul d'une somme simple ou CRC (calcul de vérification de redondance cyclique (en anglais � cyclic redundancy code �)) ; un code d'identification qui est le résultat d'un calcul complet dépendant de façon biunivoque des données de contenu, par exemple un calcul de vérification de redondance cyclique plus élaboré (CRC-8,..., CRC-16, CRC-32, CRC64-ISO, CRC64-ECMA-182) et/ou un calcul fondé sur au moins une fonction de hachage cryptographique (SHA-0, SHA-1, SHA-2, SHA-256, SHA-3 84, MD2, MD4, MD5, RIPEND, Tiger, Whirlpool) appliquée aux données de contenu. De préférence, tous les serveurs source 2 dont l'agent de collecte 8 réalise l'archivage des fichiers dans un même serveur d'archivage 5 utilisent un même procédé de calcul du code calculé. Le code calculé lors de l'étape 44 est adressé en 53 au serveur d'archivage 5. Préalablement, l'agent de collecte 8 adresse un signal de requête de connexion 51 au module de gestion d'archivage 9, et ce dernier émet un signal 52 d'acquittement de validation de connexion si cette connexion peut être établie. Le module de gestion d'archivage 9 déclenche alors, à réception de ce code calculé, un module 11 de vérification de la présence de ce code calculé mémorisé sur l'une ou l'autre de ses mémoires de masse 6, 7 associées. La figure 7 donne un exemple de réalisation du module I1 de vérification. Lors de l'étape 71, il est examiné si la taille des données (et qui est le premier nombre contenu dans le code calculé dans l'exemple mentionné ci- dessus) correspond à une taille de données de contenu déjà archivées en mémoire de masse 6, 7 du serveur d'archivage 5. Si la taille des données de contenu du fichier collecté est nouvelle, cela signifie que ces données de contenu n'ont jamais été archivées. Dans ce cas, on enregistre lors de l'étape 77 un signal 54 selon lequel les données de contenu du fichier collecté n'ont pas déjà été archivées, ce qui permet de procéder ensuite à l'étape 48 de transfert de ces données de contenu vers le serveur d'archivage 9. Par contre, s'il existe déjà des données de contenu correspondant à cette taille mémorisées en mémoire de masse 6, 7, il est examiné, lors d'une étape de test 73, parmi les différentes données de contenu correspondant à cette taille, s'il existe des données de contenu archivées en mémoire de masse 6, 7 du serveur d'archivage 5 pour lesquelles la valeur du code intermédiaire obtenu à partir du premier calcul de vérification (qui est un calcul simple, par exemple de type CRC), est la même que celle contenue dans le code calculé. Cette valeur de code intermédiaire peut être enregistrée en mémoire de masse 6, 7 du serveur d'archivage 5 en association avec les données de contenu correspondantes. Dans ce cas, il suffit dans une étape 72 précédant immédiatement l'étape de test 73, de lire cette valeur de code intermédiaire telle qu'elle est enregistrée et de la comparer à la valeur reçue dans le code calculé reçu correspondant aux données de contenu du fichier collecté. Si cette valeur de code intermédiaire n'est pas enregistrée avec les données de contenu, il suffit, lors de l'étape 72, de la calculer en utilisant bien sûr le même procédé de calcul que celui qui a été utilisé pour calculer la valeur du code intermédiaire contenu dans le code calculé reçu correspondant aux données de contenu du fichier calculé. Si la valeur du code intermédiaire contenu dans le code calculé reçu ne correspond à aucune des données de contenu enregistrées en mémoire de masse 6, 7 du serveur d'archivage 5, cela signifie que les données de contenu du fichier collecté n'ont jamais été archivées, et on enregistre lors de l'étape 77 un signal 54 selon lequel les données de contenu du fichier collecté n'ont pas déjà été archivées, ce qui permet de procéder ensuite à l'étape 48 de transfert de ces données de contenu. Si au contraire, il existe des données de contenu archivées pour lesquelles la valeur du code intermédiaire correspond à celle du code calculé reçu, on détermine lors de l'étape 74, la valeur du code d'identification pour ces différentes données de contenu archivées. Cette détermination peut être effectuée soit par simple lecture lorsque la valeur du code d'identification est enregistrée en association avec les données de contenu dans la mémoire de masse 6, 7 du serveur d'archivage 5, soit par un nouveau calcul effectué sur les données de contenu à partir du même procédé de calcul que celui qui est utilisé pour calculer le code identification des données de contenu du fichier collecté. On compare ensuite lors de l'étape 75 de la valeur du code identification contenu dans le code calculé reçu correspondant au fichier collecté, avec la valeur du code d'identification ainsi déterminée pour les différentes données de contenu archivées. S'il existe des données de contenu archivées qui présentent la même valeur de code identification, on enregistre lors de l'étape 76 un signal selon lequel les données de contenu du fichier sont déjà présentes en mémoire de masse 6, 7 du serveur d'archivage. Dans le cas contraire, on effectue l'étape 48 de transfert. Le module 11 de vérification effectue donc une recherche sur les mémoires de masse 6, 7 pour déterminer s'il existe un fichier archivé pour lequel un tel code calculé présentant cette valeur a déjà été enregistré. Le résultat de cette vérification est ensuite communiqué en 54 ou 55 à l'agent de collecte 8 du serveur source 2 correspondant via le système 1 de liaison. L'agent de collecte 8 effectue alors un test 47 à partir du résultat qu'il reçoit. Si ce résultat 54 indique que le code calculé n'est pas déjà présent sur l'une des mémoires de masse 6, 7 du serveur d'archivage 5, l'agent de collecte 8 autorise le transfert des données de contenu de ce fichier collecté à destination du serveur d'archivage 5, lors de l'étape 48 de transfert. Au contraire, si le résultat 55 indique que le code calculé est déjà présent sur l'une des mémoires de masse 6, 7 du serveur d'archivage 5, l'étape 48 n'est pas effectuée et le processus est replacé au test 41 pour la détection d'un nouveau fichier. En parallèle, après l'étape 44 de calcul du code calculé, l'agent de collecte 8 réalise une étape 45 de création de métadonnées associées au fichier collecté, puis une étape 46 de transfert systématique de ces métadonnées au serveur d'archivage 5. À l'issue de l'étape 46, le processus est replacé au test 41 pour la détection d'un nouveau fichier à collecter. Ainsi, quelle que soit la valeur du code calculé, les métadonnées d'un fichier collecté sont toujours transférées au serveur d'archivage 5. Si le module 11 de vérification du code calculé détermine que les données de contenu du fichier collecté ont déjà été archivées sur le serveur d'archivage 5, seules ces métadonnées sont transférées. Elles sont ensuite ajoutées à l'ensemble des informations concernant le fichier collecté et déjà préalablement enregistrées sur l'une ou l'autre des mémoires de masse 6, 7 du serveur d'archivage 5. À l'inverse, si le module 11 de vérification du code calculé indique que les données de contenu du fichier collecté n'ont pas été préalablement archivées ou ont été modifiées depuis le dernier archivage (code calculé absent des mémoires de masse 6, 7 associées au serveur d'archivage 5), les données de contenu constitutives du fichier collecté et enregistrées sur les mémoires de masse 3, 4 associées au serveur source 2, sont transférées avec les métadonnées pour être archivées. Lors de l'étape 45 de création des métadonnées associées au 15 fichier collecté, l'agent de collecte 8 exécute un module 14 d'extraction et de calcul de métadonnées. Les métadonnées collectées par ce module 14 comprennent des métadonnées techniques MDT qui sont mémorisées en association avec les données de contenu du fichier sur la mémoire de masse 3, 4 associée au serveur 20 source 2. Ces métadonnées MDT sont générées par le système d'exploitation OS du serveur source 2, par exemple des métadonnées décrivant le contenu technique du fichier lui-même, sa date de création, son volume (nombre de bits),... Par ailleurs, le fichier peut également être associé à une ou plusieurs application(s) logicielle(s) spécifique(s) 19 susceptible(s) de générer des 25 métadonnées d'en-tête MDE en association avec ce fichier, ces métadonnées MDE étant enregistrées dans ce fichier, avec les données de contenu du fichier, sur la mémoire de masse 3, 4 du serveur source 2. Par exemple, un fichier de traitement de texte, qui peut être identifié en tant que tel par son extension, peut faire l'objet de métadonnées MDE générées et enregistrées par un logiciel de traitement de texte qui permet de le créer ou de le modifier (par exemple un titre, un résumé, des mots-clés, l'identification d'un auteur,...). Il peut s'agir également par exemple de données représentatives de l'état d'un document, de droits d'accès à un fichier, d'une signature numérique, de certificats d'authentification... Ces métadonnées d'en-tête MDE sont accessibles par l'ouverture du fichier lui-même, ou grâce à un module logiciel API extracteur d'en-tête. Le module 14 d'extraction et de calcul de métadonnées de l'agent de collecte 8 est adapté pour pouvoir identifier ces métadonnées d'en-tête MDE, les collecter (en émettant des requêtes ciblées par exemple sur des bases de données, ou une requête directe, par exemple via une API extracteur d'en-tête, concernant le fichier collecté) et les enregistrer avec l'ensemble des métadonnées associées au fichier qui seront transférés au serveur d'archivage 5. De surcroît, le module 14 d'extraction et de calcul de métadonnées est adapté pour pouvoir générer lui-même des métadonnées MDG selon au moins traitement informatique prédéterminé, et les associer au fichier collecté, ces métadonnées MDG étant par exemple des métadonnées représentatives du contexte, sur le serveur source 2, du fichier collecté. Par exemple, les métadonnées MDG générés par le module 14 d'extraction et de calcul de métadonnées sont choisies parmi : û des métadonnées, dites métadonnées statiques MDGS, qui peuvent être définies par une saisie de l'utilisateur lors de la configuration de la collecte, par exemple par l'intermédiaire du module de gestion d'archivage 9 ; par exemple, il est possible de faire ajouter des métadonnées permettant de qualifier l'ensemble des fichiers correspondant à une collecte prédéterminée ou à une partie de collecte prédéterminée (par exemple on peut vouloir associer la qualification � commercial � à tous les fichiers de tous les répertoires correspondant à une collecte prédéterminée) ; des métadonnées, dites métadonnées calculées MDGC, obtenues par un calcul, de préférence un calcul simple, effectué sur les données de contenu du fichier concerné : par exemple, dans le cas de fichier texte, il est possible de réaliser une indexation textuelle légère fournissant des résultats statistiques sur les mots du texte ; dans le cas d'un fichier image, il est possible d'indiquer si les données de contenu du fichier correspondent ou non à une image noire, ou à une image blanche, ou autres... La figure 6 illustre un exemple de fichier, et de différentes catégories de métadonnées pouvant être extraites et calculées à partir de ce fichier. Dans l'exemple, le fichier 61 est par exemple un fichier au format MXF. Ce fichier inclut des données de contenu Dl, D2, D3. Il contient également des métadonnées qui nécessitent l'ouverture du fichier 61 ou un extracteur de métadonnées pour y accéder, à savoir des métadonnées d'en-tête MDE : MDE1, MDE2, MDE3, des métadonnées intermédiaires MDI4, MDI5 séparant les groupes de données de contenu, et des métadonnées MDF de fin de fichier. Par ailleurs, le système d'exploitation du serveur source 2 sur lequel le fichier 61 est initialement enregistré a associé des métadonnées MDT techniques à ce fichier 61. Le module 14 d'extraction et de calcul de métadonnées rassemble tout d'abord les différentes métadonnées d'en-tête MDE, techniques MDT, et les métadonnées intermédiaires MDI4, MDI5, et de fin MDF. Par ailleurs, un module 62 de création de métadonnées permet, par un ou plusieurs calculs simples, de générer des métadonnées MDGC calculées qui sont également associées aux métadonnées du fichier 61 par le module 14 d'extraction et de calcul de métadonnées. Également, le module 14 d'extraction et de calcul de métadonnées associe des métadonnées MDGS de type statique et saisies par un utilisateur lors de la configuration de la collecte pour qualifier des propriétés des fichiers collectés. Également, le module 14 d'extraction et de calcul de métadonnées peut associer au fichier 61 des métadonnées, dites métadonnées contextuelles MDC. Ces métadonnées contextuelles MDC sont générées par un module 63 de calcul de métadonnées contextuelles à partir des métadonnées MDT techniques et/ou par exemple de tout ou partie des métadonnées d'en-tête MDE1, MDE2. Ces métadonnées contextuelles MDC sont par exemple des métadonnées représentant la position du fichier collecté dans le système de gestion de fichiers du serveur source 2 et/ou l'environnement informatique de ce fichier collecté dans le système de gestion de fichiers du serveur source 2 et/ou des attributs du fichier collecté... Par ailleurs, le module 14 d'extraction et de calcul de métadonnées peut extraire des métadonnées, dites métadonnées extraites MDEX, d'un autre fichier 64, distinct du fichier 61 mais associé à ce dernier en tant que fichier de métadonnées. En effet, certains formats de fichiers prévoient des fichiers spécifiques de métadonnées, le contenu de ce fichier spécifique de métadonnées constituant des métadonnées pour le contenu d'un deuxième fichier. Tel est le cas par exemple de fichiers XML, ou de fichiers d'éditeurs de textes associés à des feuilles de style... Comme on le voit, l'agent de collecte 8 permet de regrouper toutes ces métadonnées dans un ensemble de métadonnées 65 associées au fichier collecté. Ainsi, l'agent de collecte 8 permet d'associer un grand nombre de métadonnées différentes à chaque fichier collecté, puis de transférer ces métadonnées 65 au serveur d'archivage 5, de sorte que ces métadonnées 65 sont archivées en association avec le code calculé et donc avec le fichier archivé. Cela permet ensuite d'obtenir un serveur d'archivage géré et piloté à partir de métadonnées de façon souple, dynamique et rapide. Il est à noter que tout ou partie des traitements mentionnés sur la figure 6 peuvent être effectués au niveau du module de gestion d'archivage 9, en temps réel lors de l'enregistrement du fichier archivé ou au contraire en différé, dès lors que les métadonnées correspondantes auront été préalablement transférées au serveur d'archivage 5. Sur la figure 1, on a représenté schématiquement des métadonnées MD 1 d'un fichier 61 collecté contenues dans ce même fichier 61 en association avec les données DATA correspondantes (c'est-à-dire pouvant comprendre des métadonnées techniques MDT et/ou de métadonnées d'en-tête MDE et/ou de métadonnées intermédiairesMDI4, MDI5 et/ou de métadonnées MDF de fin de fichier) ; des métadonnées MD2 enregistrées en mémoire de masse 3 du serveur source 2 mais en dehors du fichier 61 (par exemple pouvant comprendre des métadonnées d'en-tête MDE', les métadonnées extraites MDEX , et des métadonnées de fin de fichier MDF' d'un fichier 64 distinct de métadonnées), et des métadonnées MD3 générées par le module de gestion d'archivage 9 et/ou par l'agent de collecte 8 (par exemple comprenant des métadonnées contextuelles MDC, et des métadonnées calculées MDGC, et des métadonnées saisies MDGS). Le module de gestion d'archivage 9 comprend un module 15 de transfert de fichiers adapté pour contrôler le transfert de l'ensemble des données de contenu et des métadonnées du fichier collecté entre chaque serveur source 2 et le serveur d'archivage 5. Ce module 15 de transfert de fichiers a en particulier pour fonction de contrôler les différents transferts simultanés vers le même serveur d'archivage 5, par exemple selon un protocole de type FTP, notamment pour en limiter le nombre, ainsi que le taux de transfert des données à partir de chaque serveur source 2, en limitant le taux de transfert à une valeur seuil maximum prédéterminée, afin d'empêcher notamment l'occupation trop importante de la bande passante de la liaison par la fonction d'archivage. Les transferts de données de contenu et métadonnées peuvent être effectués par le module 15 de transfert de fichiers selon d'autres types de protocoles que le protocole FTP, par exemple selon des protocoles spécifiques au serveur source 2 concerné et/ou au serveur d'archivage 5. En outre, le module de gestion d'archivage 9 comprend un module 16 d'association des métadonnées adapté pour rassembler les données de contenu et les métadonnées d'un fichier collecté (dans le cas où un fichier collecté comprenant des données de contenu a été transféré au serveur d'archivage 5) et pour enregistrer de nouvelles métadonnées correspondant à un fichier déjà archivé en association avec ce fichier déjà archivé. Dans le cas où il reçoit un fichier collecté archivé comprenant à la fois des données de contenu et des métadonnées, le module de gestion d'archivage 9 active un module 17 de validation du code calculé -notamment du code identifiant- transmis préalablement aux données de contenu du fichier collecté. Ce module 17 de validation applique le même procédé de calcul que le module 12 de calcul de ce code par chaque serveur source 2. Le module de gestion d'archivage 9 connaissant l'identité du serveur source 2 d'où provient le fichier collecté, connaît également le procédé de calcul utilisé pour obtenir le code calculé -notamment le code identifiant-. Le module 17 de validation du code calculé est adapté pour appliquer ce même procédé de calcul sur les données de contenu qu'il reçoit. Si le résultat du calcul effectué par le module 17 de validation est différent du code calculé -notamment du code identifiant- transmis préalablement par le serveur source 2 en ce qui concerne les données de contenu de ce fichier collecté, un message d'erreur est adressé et les données de contenu ne sont pas archivées. Au contraire, si le résultat du calcul effectué par le module 17 de validation correspond au même code calculé -notamment au même code identifiant- que celui reçu en association avec les données de contenu du fichier collecté, ces données de contenu peuvent être archivées, c'est-à-dire enregistrées sur l'une des mémoires de masse 6, 7 associées au serveur d'archivage 5. Dans ce cas, les métadonnées MDT, MDE, MDG reçues également en association avec ce fichier collecté sont reliées aux données de contenu correspondantes et au code calculé, et l'ensemble est enregistré comme représenté figure 1 en mémoire de masse 6, 7. Dans l'exemple représenté figure 1, le code calculé est enregistré dans un champ 18 à la suite des données de contenu du fichier archivé. Ainsi, le code calculé est utilisé dans un réseau selon l'invention pour réaliser une vérification d'intégrité des données de contenu transférées au serveur d'archivage 5. Il est à noter que contrairement à ce qui est représenté schématiquement figure 1, les métadonnées MDT, MDE, MDG, les données de contenu et le code calculé ne sont pas nécessairement enregistrés ensemble en un même emplacement d'une mémoire de masse 6, 7 ou dans un même fichier. Ces différentes informations et données peuvent être réparties dans différents emplacements de la mémoire de masse, par exemple enregistrées dans différentes tables d'une base de données d'archivage. Dans le cas où le module de gestion d'archivage 9 ne reçoit que des métadonnées MDT et/ou MDE et/ou MDG correspondant à un fichier collecté, le module 16 d'association de métadonnées enregistre ces métadonnées reçues en association avec les données de contenu du fichier collecté déjà préalablement archivées en mémoire de masse d'archivage 6, 7. Il est à noter qu'un réseau selon l'invention est également compatible avec l'archivage de fichiers dont les métadonnées et/ou les données sont dupliquées sur différents serveurs source 2 eux-mêmes reliés via le système 1 de liaison, par exemple par un mode de communication du type � pair à pair �. En effet, dans ce cas, l'archivage d'un même fichier à partir de chaque serveur source 2 sur lequel permet d'associer, aux données du fichier enregistrées sur le serveur d'archivage, des métadonnées associées générées par chaque agent de collecte 8 concerné, notamment des métadonnées contextuelles permettant de connaître les différents serveurs source sur lesquels le fichier est enregistré. Par ailleurs, un serveur d'archivage 5 selon l'invention peut être doté de fonctionnalités d'indexation des données de contenu et/ou des métadonnées et/ou des fichiers archivés, de façon à faciliter les recherches et restaurations ultérieures. L'indexation peut intervenir avant l'enregistrement des informations correspondantes en mémoire de masse d'archivage 6, 7 pour les nouveaux fichiers collectés, ou au contraire peut être réalisée a posteriori sur les données de contenu et/ou métadonnées correspondant à des fichiers déjà archivés. En outre, dans un réseau selon l'invention, le module de gestion d'archivage 9 est adapté pour pouvoir récupérer toute collecte de fichiers interrompue à un moment donné pour une raison quelconque. En effet, lors du redémarrage de la collecte, l'étape d'initialisation 21 de l'agent de collecte 8 replace cet agent de collecte 8 à l'état initial précédent. La collecte redémarre alors au prochain fichier non précédemment traité. En outre, si l'interruption de la collecte intervient au cours d'un transfert de fichier, le module 17 de validation du code calculé du serveur d'archivage 5 indiquera que ce fichier n'a pas été correctement transféré, de sorte que les données de contenu de ces fichiers seront à nouveau transférées. L'invention peut faire l'objet de très nombreuses variantes de réalisations et applications différentes. En particulier, différents modules logiciels peuvent être incorporés, sans limitation, pour l'extraction ou la gestion de métadonnées, ou encore pour l'indexation. Par ailleurs, elle s'applique aussi bien quel que soit le sens que l'utilisateur pourra vouloir donner à la notion de données de contenu et à celle de métadonnées. L'invention permet en tout état de cause en effet de n'archiver en mémoire de masse des serveurs d'archivage qu'une seule fois les données considérées comme des données de contenu dans l'application considérée et définies comme telles par le fait que le procédé de calcul du code calculé, et plus particulièrement du code identifiant, s'applique uniquement sur ces données. Ainsi, rien n'empêche de prévoir que seule une partie des données de chaque fichier collecté n'est traitée comme des données de contenu. REVENDICATIONS 1/ - Réseau informatique comprenant : û au moins un serveur de fichiers, dit serveur source (2), doté d'un agent (8) de collecte de fichiers à archiver, û au moins un serveur d'archivage (5) adapté pour permettre l'archivage de fichiers sur au moins une mémoire de masse (6, 7) associée à ce serveur d'archivage, et doté d'un module de gestion d'archivage (9), û et au moins une liaison numérique (1) de réseau adaptée pour permettre l'échange d'informations numériques entre les serveurs, dans lequel : ledit module de gestion d'archivage (9) est adapté pour pouvoir émettre une commande de collecte à destination d'au moins un agent (8) de collecte d'au moins un serveur source (2), cette commande de collecte incorporant des données représentatives de critères de collecte prédéterminés, ledit agent (8) de collecte étant adapté pour exécuter sur le serveur source (2) une recherche de fichiers correspondant aux critères de collecte d'une commande reçue par ledit agent de collecte et émise par le module de gestion d'archivage, caractérisé en ce que, pour chaque fichier collecté par ledit agent (8) de collecte, ce dernier est adapté pour : calculer, à partir de données contenues dans le fichier collecté et enregistrées sur le serveur source (2), et selon un procédé de calcul unique prédéterminé, un code numérique, dit code calculé, comprenant au moins un nombre, dit code identifiant, dont la valeur dépend uniquement des dites données et dudit procédé de calcul et est propre aux dites données, transmettre le code calculé au module de gestion d'archivage, en ce que le serveur d'archivage (5) est adapté pour pouvoir, à réception d'un code calculé, rechercher s'il existe, en mémoire de masse du serveur d'archivage, des données correspondant à ce code calculé,en ce qu'il est adapté pour réaliser un transfert au serveur d'archivage (5) des dites données du serveur source contenues dans le fichier collecté et correspondant au code calculé, si le résultat de la recherche effectuée par le module de gestion d'archivage (9) est représentatif du fait que des données correspondant au code calculé ne sont pas présentes en mémoire de masse du serveur d'archivage, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces données contenues dans le fichier collecté et le code calculé associé à ces données, et en ce qu'il est adapté pour ne pas transférer au serveur d'archivage (5) lesdites données du serveur source contenues dans le fichier collecté et correspondant au code calculé, si le résultat de la recherche effectuée par le module de gestion d'archivage (9) est représentatif du fait que des données correspondant au code calculé sont présentes en mémoire de masse du serveur d'archivage. 2/ - Réseau selon la revendication 1, caractérisé en ce que ledit module de gestion d'archivage (9) est adapté pour pouvoir transmettre à l'agent (8) de collecte des données numériques représentatives du résultat de ladite recherche de données mémorisées en mémoire de masse du serveur d'archivage et correspondant au code calculé, et en ce que l'agent de collecte est adapté pour : si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que des données correspondant au code calculé ne sont pas présentes en mémoire de masse du serveur d'archivage, générer une commande d'autorisation de transfert au serveur d'archivage des données du serveur source contenues dans le fichier collecté, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces données contenues dans le fichier collecté et ce code calculé associé à ces données, si le résultat de la recherche effectuée par le module de gestion d'archivage est représentatif du fait que des données correspondant au code calculé sont présentes en mémoire de masse du serveur d'archivage, ne pas générer une commande d'autorisation de transfert des données contenues dans le fichiercollecté. 3/ - Réseau selon l'une des revendications 1 ou 2, caractérisé en ce que le module de gestion d'archivage (9) est adapté pour réaliser ladite recherche en recherchant s'il existe, en mémoire de masse du serveur d'archivage, au moins un enregistrement contenant le code identifiant. 4/ - Réseau selon la revendication 3, caractérisé en ce qu'il est adapté pour : si le résultat de la recherche effectuée par le module de gestion d'archivage (9) est représentatif du fait que le code identifiant n'est pas présent en mémoire de masse du serveur d'archivage, générer une commande de transfert au serveur d'archivage des données du serveur source contenues dans le fichier collecté, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces données contenues dans le fichier collecté et ce code identifiant associé à ces données, si le résultat de la recherche effectuée par le module de gestion d'archivage (9) est représentatif du fait que le code identifiant est présent en mémoire de masse du serveur d'archivage, ne pas générer une commande de transfert des données contenues dans le fichier collecté. 5/ -Réseau selon l'une des revendications 1 à 4, caractérisé en ce que le code calculé est calculé à partir des données du fichier collecté autres que des métadonnées de ce fichier collecté, et en ce que, pour chaque fichier collecté, l'agent (8) de collecte de fichiers est adapté pour collecter des métadonnées associées à ce fichier et, si le résultat de la recherche effectuée par le module de gestion d'archivage (9) est représentatif du fait que des données correspondant au code calculé sont présentes en mémoire de masse du serveur d'archivage, générer une commande d'autorisation de transfert partiel adaptée pour autoriser uniquement le transfert de tout ou partie de ces métadonnées au module de gestion d'archivage, ledit module de gestion d'archivage étant adapté pour mémoriser en mémoire de masse ces métadonnées en association avec les données du fichier collecté. 326/ - Réseau selon l'une des revendications 1 à 5, caractérisé en ce que, pour chaque fichier collecté, l'agent (8) de collecte de fichiers est adapté pour collecter et associer à ce fichier collecté, des métadonnées résultant de données et/ou métadonnées enregistrées sur le serveur source (2) concerné. 7/ - Réseau selon l'une des revendications 1 à 6, caractérisé en ce que, pour chaque fichier collecté, l'agent (8) de collecte de fichiers est adapté pour collecter et associer à ce fichier collecté, des métadonnées choisies parmi : û des métadonnées techniques (MDT) décrivant tout ou partie du contenu technique du fichier lui-même et associées à ce fichier ; û des métadonnées (MDE) élaborées par une application logicielle distincte et enregistrées selon une structure prédéterminée ; û des métadonnées (MDG, MDC) générées selon au moins un traitement informatique prédéterminé par l'agent de collecte. 8/ - Réseau selon l'une des revendications 1 à 7, caractérisé en ce que pour chaque fichier collecté et transféré au serveur d'archivage (5) avec au moins un code calculé, ledit module de gestion d'archivage (9) est adapté : û pour calculer un code de vérification, à partir des données contenues dans le fichier collecté telles que reçues par le serveur d'archivage et selon ledit procédé de calcul unique prédéterminé utilisé par l'agent de collecte pour calculer ledit code identifiant correspondant, û pour comparer la valeur de ce code de vérification calculée à partir des données reçues, avec la valeur de ce code identifiant transmise avec lesdites données du fichier collecté, û et pour mémoriser en mémoire de masse les données 25 contenues dans le fichier collecté si et seulement si ces deux valeurs du code de vérification et du code identifiant sont égales. 9/ - Réseau selon l'une des revendications 1 à 8, caractérisé en ce que le module de gestion d'archivage (9) comprend un module de gestion de collecte (10) adapté pour centraliser les communications entre le module de gestiond'archivage (9) et chaque agent (8) de collecte. 10/ - Réseau selon la revendication 9, caractérisé en ce que le module de gestion de collecte (10) comprend un module de transfert de fichiers adapté pour contrôler le transfert des données de chaque fichier collecté entre un serveur source (2) et le serveur d'archivage (5). 11/ - Réseau selon la revendication 10, caractérisé en ce que le module de transfert de fichiers est adapté pour limiter le nombre de transferts simultanés vers le serveur d'archivage (5) et/ou le taux de transfert des données à une valeur seuil maximum prédéterminée.