FR 2878673 A1 20060602 FR 0452788 A 20041126 SYSTÈME ET PROCÉDÉ DE SAUVEGARDE DISTRIBUÉE PÉRENNE La présente invention se rapporte au domaine des réseaux informatiques et de la sauvegarde des données 5 numériques sur de tels réseaux. La présente invention concerne plus particulièrement un procédé, un système et un dispositif pour la sauvegarde distribuée des données sur un réseau ne comprenant pas de serveur dédié aux opérations de sauvegarde. L'invention proposée assure une distribution des tâches de sauvegarde sur l'ensemble des éléments de stockages connectés au réseau, tout en mettant en oeuvre des mécanismes de pérennisation des données de commande et de contrôle ainsi que des données numériques stockées. Le but est de créer un réseau pair à pair, où de nombreux terminaux connectés à Internet s'associent pour fournir un service de stockage pérenne. Chaque micro- ordinateur jouera le rôle de périphérique de stockage. Si le micro-ordinateur est en panne, volé ou détérioré, son remplacement par un neuf permettra malgré tout de retrouver l'information stockée. L'art antérieur connaît déjà, par la demande de brevet américain US 2004 / 0 049 700 (Takeo Yoshida), un procédé de stockage de données à faible coût utilisant les capacités disponibles des ordinateurs personnels connectés au réseau. Lorsqu'un client de sauvegarde d'un PC utilisateur reçoit une instruction de sauvegarde d'un fichier par un utilisateur, le client de sauvegarde fait une demande de sauvegarde auprès du serveur de commande de sauvegarde. Ce serveur divise et chiffre le fichier à sauvegarder en une pluralité de pièces chiffrées, transfert les pièces chiffrées aux PC utilisateurs et stocke la pièce chiffrée dans le disque dur des PC utilisateurs. Lorsque le fichier sauvegardé de façon distribuée doit être extrait, le PC utilisateur obtient chaque pièce chiffrée des autres PC utilisateurs sur lesquels elles ont été stockées, et les combine et déchiffre les pièces pour restaurer le fichier original. La solution proposée est de distribuer le stockage des données par une dispersion des données sur un ensemble de périphériques connectés au réseau. Cependant ce système nécessite une forte disponibilité des périphériques, ou tout du moins qu'ils soient activables à distance, pour accéder aux données. L'autre inconvénient de ce système est qu'il ne permet pas de faire face à la défaillance des périphériques de stockage, et la perte des données sur un périphérique de stockage est irrémédiable. Enfin ce système ne passe pas à l'échelle car la coordination du stockage est assurée par un serveur par lequel transite toutes les données. L'art antérieur connaît également, par la demande de brevet PCT WO 02 / 063 484 (SS8 Networks), un système de stockage de données réparties à architecture hautement évolutive et hautement disponible. Dans un mode de réalisation de l'invention, ce système de stockage de données réparties comprend une pluralité d'unités de stockage de données qui sont commandées par un système de gestion d'objets. Ce système de gestion d'objets sélectionne des unités de stockage de données pour réaliser les demandes d'accès d'un fichier en fonction des entrées/sorties auxquelles ces demandes d'accès de fichiers sont associées. En réponse à une demande de création d'un fichier associée à une entrée externe d'une unité de stockage de données réparties, le système de gestion d'objet crée de préférence un fichier de données dans cette unité de stockage de données réparties. En réponse à une demande de localisation de fichier associée à un fichier de données et à une sortie externe d'une unité de stockage de données réparties, le système de gestion d'objet retourne de préférence un nom d'hôte et un nom d'accès d'une copie du fichier de données qui est stocké dans cette unité de stockage de données réparties. Ce système de gestion d'objet fait aussi des copies redondantes des fichiers de données dans différentes unités afin d'offrir une haute disponibilité. Dans cette demande de brevet, le système réalise un stockage distribué redondant nécessitant néanmoins un système de gestion centralisé assimilable à un serveur de gestion. La solution proposée n'est pas viable sans la présence de ce serveur, ce qui la rend extrêmement dépendante du bon fonctionnement du serveur. On connaît également, par la demande de brevet américain US 2002 / 0 114 341 (Andrew Sutherland et autres), un système de mémoire pour entités homologues comprenant un coordinateur de mémoire gérant de manière centralisée des ressources mémoire réparties conformément à des règles de système administrées par l'intermédiaire d'une console administrative centrale. Les ressources mémoire sont des portions inutilisées des moyens de stockage, par exemple, les disques durs qui sont inclus dans les dispositifs tels que les ordinateurs personnels, les stations de travail, les ordinateurs portables, les serveurs de fichiers, etc., qui sont connectés à un réseau informatique. Cette demande de brevet propose un stockage distribué 30 sur un réseau nécessitant la présence d'un coordinateur de stockage (storage coordinator), sorte de serveur, qui assure la distribution des données à stocker sur les différents dispositifs ou noeuds du réseau. De même, la demande de brevet américain US 2004 / 064 693 (Akhil K. Arora et autres) porte sur un mécanisme d'indexation distribué pour indexer et rechercher les informations d'authentification dans les réseaux pair-àpair. Un index distribué, de type DHT, peut être utilisé pour stocker l'information d'identité de façon décentralisé sur une pluralité de noeuds pairs. L'information d'identité peut être utilisée par exemple pour authentifier les utilisateurs. Des index distribués permettent à l'information d'identité d'être diffusée à travers de multiples noeuds pairs de telle sorte que la charge soit diffusée parmi les nombreux noeuds pairs. Cette demande propose d'utiliser la DHT pour mettre en place un mécanisme d'identification (d'utilisateurs ou autre) distribué. Les pairs d'une DHT sont rendus actifs (par les demandes d'information d'authentification) pour ne pas restreindre le stockage à un simple stockage passif, mais leur utilisation ne dépasse pas ce cadre et ne permet pas la détection de pannes sur un autre noeud. On connaît également, dans l'état de la technique, les réseaux pair-àpair (peer-to-peer) utilisant les tables de hashage distribuées, aussi appelées DHT (Distributed Hash Table) telles que Chord, CAN, Pastry ou Tapestry, pour réaliser un stockage distribué des données. L'utilisation des DHT dans de tels réseaux offre un mécanisme de routage entre les pairs par un sur-réseau ou overlay tolérant aux pannes et une plus grande résistance aux attaques liée à l'association routage-overlay. Elle offre également un dictionnaire distribué et redondant sur ce surréseau: chaque entrée de ce dictionnaire est composée d'une clé et d'un objet associé (par exemple un fichier de données numériques). L'objet est inséré dans la DHT qui le réplique sur différents noeuds afin d'assurer un certain niveau de tolérance aux pannes. L'utilisation de la DHT offre également une organisation logique des données: un identificateur unique est affecté à chacun des pairs, idéalement les identificateurs sont choisis de telle manière que ceux-ci soient les plus dispersés possible dans l'espace des noms disponibles, et une fonction (par exemple l'identité) projette l'espace des clés du dictionnaire dans l'espace des noms des pairs. Lors de l'insertion d'un nouvel objet dans le dictionnaire DHT, le pair qui le stockera est celui qui sera atteint par l'algorithme de routage en fonction de la clé projetée de l'objet dans l'espace des noms; en général, l'algorithme de routage désigne le pair qui a l'identifiant le plus proche de la projection de la clé. L'objet inséré est répliqué par la DHT pour faire face à la disparition de pairs. Typiquement, chaque pair maintient une liste des pairs qui ont un identifiant voisin (au sens de l'algorithme de routage) dans l'espace des noms, l'objet est alors dupliqué sur ces pairs. Les mécanismes connus associés aux DHT permettent de gérer les données par de simples primitives telles que search, put, get, free, ... Une autre limitation concerne l'utilisation lourde des DHT: elles stockent les données, ce qui accroît conséquemment le trafic sur le réseau lorsque des requêtes sont émises. La présente invention entend remédier aux inconvénients de l'art antérieur en proposant un procédé de sauvegarde distribuée sur un réseau informatique basé sur l'utilisation des tables de hashage distribuées pour stocker de façon pérenne les informations de commande et de contrôle ou de gestion de stockage. On entend par informations de commande et de contrôle ou de gestion toutes les données associées aux données à stocker, aux n uds du réseau qui sont utilisées lors du stockage ou lors de la récupération des données. Le procédé selon la présente invention répond particulièrement bien aux problématiques des réseaux informatiques actuels: évolution du réseau par ajout/retrait de nouveaux noeuds, sécurité contre les attaques, protection des données, redondance des informations de stockages, pérennisation des données lors de pannes ou défaillances. À cet effet, l'invention concerne dans son acception la plus générale un procédé de sauvegarde distribuée d'un bloc B de données numériques sur un réseau informatique comprenant une table de hashage distribuée DHT et au moins trois noeuds NO, les noeuds NO étant connectés audit réseau, ledit procédé comprenant une étape de division dudit bloc B en r fragments F de données numériques, ledit procédé comprenant, en outre, les étapes suivantes: une étape de stockage d'un fragment F dans les ressources mémoires d'un noeud NOF; une étape d'enregistrement dans les parties de la DHT contenues sur au moins deux noeuds, des couples (bloc B, noeud NOF) et (noeud NOF, fragment F). et, lors dudit procédé, aucune opération sur la DHT ou opération de stockage n'est réalisée sur un serveur centralisé. Selon un mode de réalisation, ledit procédé comprend, suite à ladite étape de division, une étape de calcul de s fragments de redondance calculés à partir desdits r fragments F. Selon un mode de réalisation particulier, lesdits fragments sont stockées, lors de l'étape de stockage, sur des noeuds tous différents. Particulièrement, la DHT ne contient que des données de contrôle et aucun fragment de données. Selon une mise en oeuvre, ledit procédé comprend, en outre, une étape d'envoi périodique par chacun desdits noeuds d'une information d'activité à un ensemble de noeuds sélectionnés par la DHT. Dans un mode de réalisation, la DHT contient un champ cycle de vie et en ce que l'envoi de ladite information d'activité met à jour le champ cycle de vie dudit noeud, ledit champ étant présent sur l'ensemble des noeuds sélectionnés par la DHT. Selon une mise en oeuvre particulière, ledit procédé 20 comprend, en outre, une étape de détection d'un champ cycle de vie non mis à jour par un noeud Cpanne. Particulièrement, ledit procédé comprend, en outre, une étape de reconstruction des données stockées sur ledit noeud en panne Cpanne et de mise à jour, dans la DHT, de la liste des noeuds stockant au moins un fragment dudit bloc B. Dans un mode de réalisation, les fragments reconstruits lors de ladite étape de reconstruction sont 30 stockés chacun sur au moins un autre noeud sain. Dans un mode de réalisation particulier, ledit procédé comprend, en outre, une étape de récupération dudit bloc B. 2878673 8 Particulièrement, ladite étape de récupération comprend une première étape d'envoi d'une requête du noeud demandeur à la DHT, une seconde étape où la DHT lui renvoie les noeuds stockant les fragments du bloc, une étape d'envoi de requête de récupération de fragments à ces noeuds et une étape de reconstruction du bloc B dès la réception de F fragments différents. L'invention concerne également un dispositif de sauvegarde distribuée de données pour la mise en oeuvre du procédé comprenant un processeur, une mémoire de stockage, des moyens de connexion au réseau et des moyens de contrôle des données distribuées, du type table de hashage distribuée DHT. Selon un mode de réalisation, ledit dispositif est sous forme d'un boîtier externe que l'on ajoute à un poste informatique déjà existant. L'invention concerne également un système de sauvegarde distribuée comprenant au moins deux dispositifs précédents connectés entre eux par un réseau informatique. Particulièrement, ledit système comprend une pluralité 25 de dispositifs connectés à plusieurs réseaux interconnectés. On comprendra mieux l'invention à l'aide de la description, faite ciaprès à titre purement explicatif, d'un mode de réalisation de l'invention, en référence aux figures annexées: - la figure 1 représente l'architecture globale d'un réseau pair-à-pair selon la présente invention; la figure 2 illustre l'architecture logicielle du système; la figure 3 illustre l'architecture du dispositif de stockage distribué ; la figure 4 représente un exemple de structure de la table de hashage distribuée; la figure 5 illustre la réplication et la décomposition d'un bloc de données avant le stockage distribué ; la figure 6 illustre la surveillance des pairs du réseau par la mise à jour dynamique de la DHT par chaque pair; - la figure 7 illustre les échanges entre les différents éléments du réseau lors de l'initialisation du réseau; la figure 8 illustre les échanges lors de l'écriture (sauvegarde) de données sur le réseau selon la présente invention; - la figure 9 illustre les échanges lors de l'étape de récupération de données dans le réseau; - la figure 10 représente les échanges entre les différents éléments du réseau lors de la reconstruction des données perdues d'un pair défaillant. La présente invention propose un procédé, un système et un dispositif de stockage distribué et pérenne de données pair à pair utilisant l'espace disque disponible sur des pairs pour y entreposer les données des utilisateurs. La solution proposée permet de proposer un système de stockage indépendant de la robustesse de composants locaux (typiquement le disque dur). Les données sont à l'abri d'une détérioration accidentelle (incendie) ou autre (vol du matériel par exemple). La disponibilité des données est également garantie par le système qui met en oeuvre son processus de réplication dès lors qu'il est connecté au réseau. La propriété de sauvegarde en temps réel et la disponibilité des données ne sont pas assurées dans la plupart des systèmes de sauvegarde qui réalisent des copies des données à protéger à intervalles réguliers (sauvegarde de type incrémentale sur CD-Rom ou réseau). La pérennité est, quant à elle, assurée par les propriétés de tolérance aux fautes, mises en oeuvre en particulier par la fragmentation des données et l'ajout de redondance, le tout associé à un mécanisme de détection de pannes et de réparation dynamique des fragments perdus. La figure 1 illustre l'architecture des systèmes pairà-pair selon la présente invention. Une pluralité de pairs (1) sont connectés à un réseau (2) constituant un réseau maillé. Les données numériques à sauvegarder peuvent circuler sur toutes les branches du réseau. Les données de contrôle (ensemble des informations de gestion des données stockées de façon distribuée) circulent sur le même réseau par un mécanisme adapté : celui des DHT comme décrit dans l'art antérieur. Toute requête sur la DHT est réalisée par n'importe quel chemin du réseau au même titre qu'une donnée est envoyée sur le réseau. On entend par pair tout noeud du réseau pouvant être simplement un ordinateur. Les réseaux pair-à-pair se basent sur une égalité entre tous les noeuds du réseau, c'est-à-dire que chacun des postes informatiques joue le même rôle que les autres. Ce système ne comporte aucun serveur centralisant une quelconque opération ou gestion de stockage. Certains serveurs dédiés à d'autres tâches peuvent être présents sur le réseau sans altérer le fonctionnement de l'invention: ils sont vus comme de simples pairs du réseau. Le réseau (2) utilisé peut être simplement un réseau d'entreprise, mais sera idéalement l'Internet. Dans ce cas, la présente invention offre une solution de stockage distribué sur toute la planète. La figure 2 illustre l'architecture logicielle du système au niveau d'un poste client (n ud du réseau). Le système selon la présente invention se compose de deux entités principales: un Client (20) qui est un demandeur d'espace et un Fournisseur (21) qui alloue et gère l'espace. L'invention réalise un stockage de bas niveau: le système peut être vu comme un disque dur virtuel. Le Client peut être un système de fichiers spécifique (CFS, NFS, Fuse, ...) interfacé avec le réseau pour permettre à l'utilisateur de gérer ses données sous forme de fichier. Le réseau selon la présente invention est inter-opérable avec d'autres systèmes de stockage, tel que IBP (Internet Backplane Protocol), Past... Prenons par exemple un utilisateur qui envoie son fichier (26) au système de fichiers, interfacé avec la présente invention. Ce fichier est découpé en blocs (25) qui sont ensuite envoyés au Répartiteur (22). Ce dernier détient les informations sur les ressources disponibles en interrogeant le Manager des Ressources (24). Le Répartiteur découpe les blocs en fragments en incluant des fragments de redondance et de correction (Reed- Salomon). Finalement il répartit ces fragments sur des pairs dédiés au stockage, les Stockeurs (23), qui sauvegardent localement les fragments. La gestion de l'espace de stockage partagé repose donc sur trois applications différentes: ^ le Client (20) est l'interface utilisateur pour demander de stocker des blocs, de les récupérer ou de les effacer; ^ le Répartiteur (22) est le fournisseur de service, il détient et gère les informations sur les ressources; et ^ le Stockeur (23) est le pair qui enregistre les données sous forme de fragments sur le disque dur local. Chacun des noeuds du réseau dispose de ces trois applications puisqu'ils sont tous susceptibles de jouer le rôle de demandeur ou de stockeur. Le Manager des Ressources (24) est l'organe central de la gestion du système. Il mémorise l'état de chaque Stockeur (il connaît la liste de tous les fragments archivés sur les Stockeurs), prend en charge la détection des noeuds morts et active la reconstruction des fragments lors de la disparition des Stockeur. Dans l'art antérieur, le Manager de Ressources (24) repose sur des serveurs dédiés: la gestion du système est concentrée sur le Manager des Ressources et constitue donc un point faible dans l'architecture du système puisque sa position centrale en fait une cible privilégiée pour une attaque de Denis de Service. La présente invention propose de distribuer les fonctions du Manager des Ressources (24) sur l'ensemble des clients (noeuds) du réseau afin d'améliorer la résistance du système à la défaillance simultanée (volontaire ou accidentelle) d'un nombre important de pairs. Ces moyens distribués mémorisent l'état de chaque Stockeur, possèdent la liste de tous les fragments archivés sur les Stockeurs, prennent en charge la détection des noeuds morts et activent la reconstruction des fragments lorsque cela est nécessaire pour préserver la pérennité des données. Dans un mode de réalisation illustré par la figure 3, le dispositif de stockage (30) selon la présente invention se compose d'un processeur CPU (31) contrôlant une mémoire vive (33) de type RAM (Random Access Memory), une mémoire de stockage (32) de type disque dur et des moyens de connexion au réseau (36), par exemple une carte réseau. Un système d'exploitation (34) est exécuté sur le processeur et permet aux applications (35) mentionnées précédemment d'être exécutées. Par exemple, une carte mère de faible dimension et de faible consommation, avec un processeur type x86, une mémoire vive, un disque dur et une carte réseau (par exemple fast ethernet). Le tout est intégré dans un boîtier de faible dimension. Le boîtier est connecté au réseau local de l'entreprise et peut aussi accéder au réseau des autres boîtiers similaires (par exemple sur Internet) pour assurer le service de stockage. Ce dispositif peut être intégré dans un ordinateur déjà existant. Pour garantir la sécurité de l'invention, le dispositif peut consister en un boîtier externe ajouté à un noeud du réseau, le boîtier pouvant utiliser, selon le mode de réalisation choisi, certaines ressources de l'ordinateur (connexion réseau par exemple). La présente invention propose un mécanisme permettant de distribuer le Manager des Ressources (24) précédemment évoqué. Ce mécanisme tend à porter sur les pairs du réseau l'ensemble de la gestion des ressources. De nouvelles architectures proposent des mécanismes de routage entre les pairs basés sur un sur-réseau (overlay) et ainsi que des systèmes de gestion des ressources reposant sur des tables de hashage distribuées ou DHT (Distributed Hash Table). Comme évoquée dans l'art antérieur, l'utilisation des DHT pour le stockage distribué offre une réplication des données afin d'assurer une tolérance aux pannes. Dans une DHT, la complexité en communication est fonction du nombre de pairs et des données, ce qui engendre un surcoût non négligeable en termes de communication dans le réseau. En particulier lorsque la taille des données est considérable, ce qui est le cas pour un réseau de sauvegarde distribuée. C'est pour cette raison que la DHT selon la présente invention est utilisée uniquement pour stocker des méta-données, qui ont une taille beaucoup moins importante que les données elles-mêmes. On entend par méta-données les données de contrôle de la distribution du stockage (données portant sur les noeuds, sur les fragments de données sur chaque noeud, ...). La DHT a aussi un rôle de cache mémoire afin d'augmenter les performances globales du système. Illustrée par la figure 4, la table de hashage distribuée comporte six objets: ^ DNSlike: cet objet fait le lien entre le NodeID (l'identifiant du noeud) et l'adresse physique (l'adresse IP) de chaque pair; ^ Cycle de vie (LifeCycle) : chaque pair, représenté par son NodeID, stocke régulièrement un message de présence, ce message représente son cycle de vie; ^ RootID lors du stockage d'un bloc, le pair Client stocke son RootID qui représente le pointeur sur le Bloc Racine contenant toutes les informations nécessaires pour récupérer l'ensemble des blocs du client; ^ Action: le Répartiteur stocke les commandes non encore exécutées. En cas de panne du Répartiteur, celui-ci pourra toujours rééxecuter les commandes pendantes. L'exemple le plus courant est l'effacement des blocs: si des Stockeurs ne sont pas disponibles, il est nécessaire de pouvoir rééxecuter ultérieurement la commande; ^ Fragments: chaque Stockeur stocke au sein d'une DHT la liste de tous ses fragments; et ^ Blocs: lors du stockage d'un bloc, le pair client stocke la liste des NodelD contenant les fragments du bloc identifié par son BlocID (identifiant unique du bloc). Les quatre premiers objets ont pour but la collecte d'informations fonctionnelles et comportementales des pairs, tandis que les deux derniers concernent le stockage des données sur les différents pairs. Les différentes étapes mises en oeuvre dans la présente invention sont les suivantes: ^ L'étape d'initialisation lorsqu'un nouveau pair incorpore le réseau est illustrée par la figure 7. Chaque client qui servira de points d'entrée à l'overlay calcule son NodelD en fonction d'une certaine métrique, par exemple en fonction de sa géolocalisation. Cet identifiant est conservé pendant toute la vie du pair. Les pairs sont ajoutés un par un dans l'overlay. Chaque pair en passe d'intégrer le réseau calcule un NodelD unique. Les pairs contactent le point d'entrée le plus proche numériquement dans la liste qu'il connaît et s'insère en fonction de son NodelD dans l'overlay et reconstitue sa propre table de routage à l'aide de ses voisins. À la naissance d'un pair, en plus de son identifiant unique le NodelD, le pair obtient une liste de BloclD. Les différents noeuds du réseau mettent à jour (71) le Manager de Ressources, i.e. la DHT. ^ L'étape de maintenance qui consiste à ce que chaque pair stocke ou met à jour au sein de la DHT son objet DNSlike qui contient les informations concernant l'association de son NodeID avec son IP, ainsi que son cycle de vie. De cette manière pour savoir quand un pair se déconnecte où s'il est en panne, il suffit de lire la DHT. Étant donné qu'il est possible de récupérer la liste des fragments qu'un pair possède: la reconstruction des fragments perdus par la perte d'un pair est toujours possible. ^ L'étape de stockage d'un bloc est illustrée par la figure 8: un pair Pi souhaite stocker un bloc Bi. Illustré par la figure 5, le bloc à stocker (50) peut être répliqué en plusieurs blocs (50a, 50b et 50c) pour autoriser une tolérance aux pannes (ici deux blocs peuvent être perdus sans altérer les données). Il calcule un numéro de groupe virtuel en fonction du BlocID. Puis le pair Pi obtient par la DHT la liste des NodeID des Stockeurs correspondant au groupe virtuel GVi={Pli...; Pf} . Un groupe virtuel est un ensemble de f pairs sélectionnés de façon à minimiser la corrélation de mort simultanée. De façon plus détaillée: Client: Le pair client Pi envoie un bloc Bi à un Répartiteur (81). - Répartiteur: Le Répartiteur découpe le bloc reçu (50) Bi en f fragments: s fragments de segmentation (51) et r fragments de redondance (52) (par exemple une redondance Reed-Salomon), comme illustré sur la figure 5. Ensuite le Répartiteur envoie une requête (83) de recherche d'un pair, de P1 jusque Pf. Les NodeID obtenus (84) serviront à la composition du groupe virtuel associé au stockage du bloc Bi. Le Répartiteur stocke (85) les fragments sur les pairs indiqués, nommés Stockeurs. - Stockeur: il stocke des fragments issus de divers blocs. Les Stockeurs mettent à jour leur liste de fragments et la communique à la DHT. Chaque Stockeur envoie un acquittement au Répartiteur lors de la réception d'un fragment. - Répartiteur après validation des opérations précédentes par les acquittements, le Répartiteur stocke (86) dans une DHT, avec pour clé le BloclD, les NodelD correspondant aux Stockeurs stockant le BloclD. Enfin le Répartiteur informe (82) le client du bon déroulement du stockage de son bloc Bi par l'envoi d'un acquittement. ^ L'étape de récupération/réception d'un bloc est illustrée par la figure 9: un pair Pi souhaite recevoir son bloc Bi préalablement stocké. L'action se déroule de la façon suivante: Client: Le pair client envoie une demande de réception (91) du bloc Bi au Répartiteur. - Répartiteur: Le Répartiteur envoie une requête à la DHT (95) pour demander le BloclD correspondant, la DHT lui renvoie (96) la liste des NodelD stockant les fragments composant les blocs. Le Répartiteur interroge alors la DHT pour connaître les IP des Stockeurs en fonction des NodeID donnés. Le Répartiteur demande les fragments aux Stockeurs correspondants aux NodelD fournis: Stockeur: A la demande du Répartiteur (93), il envoie (94) le fragment stocké. - Répartiteur: Lorsque le Répartiteur a reçu s fragments parmi les s + r,les fragments sont alors utilisés pour reconstruire le bloc Bi. Le Répartiteur envoie le bloc Bi au Client (92). La présente invention concerne également les mécanismes permettant de surveiller en permanence l'état du réseau et des pairs, et de procéder, le cas échéant, à la reconstruction des données perdues par la défaillance d'un ou plusieurs éléments du réseau. La surveillance des pairs s'appuie toujours sur la DHT, et plus précisément sur l'objet LifeCycle de chacun des pairs, comme illustré par la figure 6. La DHT met en place le procédé de duplication des données de contrôle qui font que plusieurs pairs vont recevoir le "cycle de vie". Le pair envoie régulièrement son cycle de vie à des pairs sélectionnés par la DHT qui, de ce fait, surveille l'activité de ce pair. La détection des pannes est assurée de la manière suivante chaque pair, par exemple N8, communique à intervalles réguliers à la DHT, un message qui alimente dans la DHT le cycle de vie LifeCycle du pair. Cet objet est envoyé en fonction du NodeID du pair sur les plus proches voisins (N1, N21, N56, ...) (par exemple, les plus proches voisins sont ceux dont le NodeID est le plus proche de celui du pair N8) du pair NodeID N8. Si le pair n'est pas en panne, l'objet concernant son cycle de vie se retrouve stocké chez lui et chez les k-1 pairs plus proche numériquement de son NodeID, par les mécanismes de réplication de données inhérents aux DHT (k est un paramètre qui permet de fixer la tolérance aux pannes de k1 éléments). Nous pouvons remarquer que si le pair se déconnecte de manière logicielle, une mise à jour de son cycle de vie est envoyée avant la déconnexion effective du pair. Ainsi, les k-1 pairs peuvent analyser dans la DHT locale (sans communication), l'état du cycle de vie du pair donné. De cette façon, chaque pair lit le cycle de vie des autres pairs associés par le routage au sein de la DHT. Lorsqu'un pair N21 détecte une anomalie concernant le cycle de vie du pair N8 (absence de la dernière mise à jour), il en réfère aux k-1 autres pairs désignés par l'overlay. Le pair N21 rentre dans une phase de concertation avec les k-1 pairs et en fonction des informations qui lui sont communiquées, le pair initiateur de la requête peut déclencher ou non une reconstruction des données perdues du n ud N8. Cette étape de concertation peut être réalisée par un algorithme dit des généraux byzantins pour faire face à des pairs malveillants dans la prise de décision. Plusieurs phases d'échange total d'informations entre les pairs sont réalisées, dans lesquelles chacun communique son avis sur la défaillance du pair concerné. Les multiples phases permettent de détecter les pairs incohérents et de prendre une bonne décision avec un certain niveau de garantie: les algorithmes les plus connus tolèrent jusqu'à la malveillance d'au plus un tiers des pairs. Si une reconstruction est demandée alors qu'elle n'est pas nécessaire cela n'est pas préjudiciable au système. Il faudra toutefois gérer le fait que la détection n'est pas fiable, en contrôlant constamment le processus de reconstruction. Illustrée par la figure 10, la reconstruction des données perdues du pair défaillant N8 est déclenchée par le pair N21 qui a détecté la panne. N21 demande (101) à la DHT les fragments que stockait le pair N8 en panne. Dans un mode de réalisation de l'invention, les mécanismes de routage et de nommage permettent que le pair détienne lui-même une partie des informations propres aux données qu'il contient et que ses proches voisins contiennent. Ainsi, cette opération ne peut nécessiter aucune communication, seulement la consultation de la table DHT. La recherche est effectuée en fonction du NodelD du pair en panne. Une requête (102) est alors lancée pour récupérer ces fragments. Une fois la liste des fragments récupérée (103), le pair déduit l'ensemble des blocs endommagés et demande la.reconstruction des fragments perdus. Ces fragments sont reconstruits grâce au mécanisme de redondance et ils sont stockés sur des pairs sélectionnés par la même méthode que lors du stockage initial du bloc. Lorsque l'opération est terminée, le pair met à jour la liste des NodelD pour le BloclD, dans la DHT. La présente invention met également en uvre des 15 mécanismes annexes permettant d'accroître la sécurité du système. Entre autres, la sécurisation des communications entre pairs concerne: la connexion des (nouveaux) pairs sur le 20 réseau qui repose sur une liste de n uds de confiance qui sont les serveurs dédiés; l'identification des pairs afin d'éviter la connexion d'un n ud malveillant au réseau. Cette identification s'appuie sur les systèmes d'authentification à clé publique; ^ la confidentialité des transactions met en uvre un chiffrement (chiffrement, embrouillage, transposition) des données de transaction entre les pairs par l'utilisation d'une clé secrète chiffrée par la clé publique du pair. REVENDICATIONS 1. Procédé de sauvegarde distribuée d'un bloc B de données numériques sur un réseau informatique comprenant une table de hashage distribuée DHT et au moins trois noeuds NO, les noeuds NO étant connectés audit réseau, ledit procédé comprenant une étape de division dudit bloc B en r fragments F de données numériques, ledit procédé étant caractérisé en ce qu'il comprend, en outre, les étapes suivantes: une étape de stockage d'un fragment F dans les ressources mémoires d'un noeud NOF; une étape d'enregistrement dans les parties de la DHT contenues sur au moins deux noeuds, des couples (bloc B, noeud NOF) et (noeud NOF, fragment F) ; et caractérisé en ce qu'aucune opération sur la DHT ou opération de stockage n'est réalisée sur un serveur centralisé. 2. Procédé de sauvegarde distribuée selon la revendication précédente, caractérisé en ce qu'il comprend, suite à ladite étape de division, une étape de calcul de s fragments de redondance calculés à partir desdits r fragments F. 3. Procédé de sauvegarde distribuée selon la revendication précédente, caractérisé en ce que lesdits fragments sont stockées, lors de l'étape de stockage, sur des noeuds tous différents. 4. Procédé de sauvegarde distribuée selon l'une des revendications précédentes, caractérisé en ce que la DHT ne contient que des données de contrôle et aucun fragment de données. 5. Procédé de sauvegarde distribuée selon l'une quelconque des revendications, précédentes caractérisé en ce qu'il comprend, en outre, une étape d'envoi périodique par chacun desdits noeuds d'une information d'activité à un ensemble de noeuds sélectionnés par la DHT. 6. Procédé de sauvegarde distribuée selon la revendication précédente, caractérisé en ce que la DHT contient un champ cycle de vie et en ce que l'envoi de ladite information d'activité met à jour le champ cycle de vie dudit noeud, ledit champ étant présent sur l'ensemble des noeuds sélectionnés par la DHT. 7. Procédé de sauvegarde distribuée selon la revendication précédente caractérisé, en ce qu'il comprend, en outre, une étape de détection d'un champ cycle de vie non mis à jour par un noeud Cpanne 8. Procédé de sauvegarde distribuée selon la revendication précédente caractérisé, en ce qu'il comprend, en outre, une étape de reconstruction des données stockées sur ledit noeud en panne Cpanne et de mise à jour, dans la DHT, de la liste des noeuds stockant au moins un fragment dudit bloc B. 9. Procédé de sauvegarde distribuée selon la revendication précédente, caractérisé en ce que les fragments reconstruits lors de ladite étape de reconstruction sont stockés chacun sur au moins un autre noeud sain. 10. Procédé de sauvegarde distribuée selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend, en outre, une étape de récupération dudit bloc B. 11. Procédé de sauvegarde distribuée selon la revendication précédente, caractérisé en ce que ladite étape de récupération comprend une première étape d'envoi d'une requête du noeud demandeur à la DHT, une seconde étape où la DHT lui renvoie les noeuds stockant les fragments du bloc, une étape d'envoi de requête de récupération de fragments à ces noeuds et une étape de reconstruction du bloc B dès la réception de F fragments différents. 12. Dispositif de sauvegarde distribuée de données pour la mise en uvre du procédé selon l'une quelconque des revendications précédentes comprenant un processeur, une mémoire de stockage, des moyens de connexion au réseau et des moyens de contrôle des données distribuées, du type table de hashage distribuée DHT. 13. Dispositif de sauvegarde distribuée selon la revendication précédente, caractérisé en ce qu'il est sous forme d'un boîtier externe que l'on ajoute à un poste informatique déjà existant. 14. Système de sauvegarde distribuée comprenant au moins deux dispositifs selon l'une quelconque des revendications 12 et 13, lesdits dispositifs étant connectés entre eux par un réseau informatique. 15. Système de sauvegarde distribuée selon la revendication précédente, caractérisé en ce que ledit système comprend une pluralité de dispositifs selon l'une des revendications 12 ou 13, lesdits dispositifs étant connectés à plusieurs réseaux interconnectés.