Brevet FR2872938A1 — publié le 20060113

La présente invention concerne le partage d'une donnée numérique à travers un réseau de communication distribué. Elle trouve une application particulière dans le partage, le stockage et l'accès à des données numériques multimédia dans un réseau de communication distribué de type poste à poste, appelé encore pair à pair ou peer to peer en anglais. Par la suite, le terme donnée numérique , document numérique ou fichier peut s'appliquer à la fois à des images, des textes ou des vidéos numériques. Le terme version désigne une résolution particulière de la donnée. La donnée originale possède la résolution la plus élevée. La donnée ayant une résolution plus faible que celle de la donnée originale est appelée vignette . Dans le cas où la donnée numérique est une image, la donnée originale correspond à l'image originale, c'est à dire à pleine résolution, tandis que la vignette correspond à une image de résolution inférieure. Dans le cas où la donnée est une vidéo, la donnée originale correspond à la séquence d'images originales, tandis que la vignette correspond, par exemple, à la première image de la vidéo ayant une résolution inférieure à celle de la vidéo originale. Les systèmes de communication pair à pair sont différents des systèmes de communication client/serveur traditionnels car dans les systèmes pair à pair, chaque poste ou machine peut être à la fois client et serveur. Ainsi, un poste peut à la fois recevoir et servir des fichiers, y compris ceux que le poste pair a déjà reçus. De plus, les données sont servies directement à partir des machines des utilisateurs. La place de stockage peut donc être considérée en pratique comme illimitée. Cependant, les postes pairs ne sont pas toujours connectés et leur adresse peut changer à chaque connexion. On sait remédier à ce problème en utilisant un serveur central qui garantit un minimum de qualité de service. On parle alors de réseau de 30 communication pair à pair hybride. Néanmoins, la recherche d'un document est encore difficile dans un tel réseau pair à pair hybride. On sait améliorer cette recherche en associant un identifiant unique à chaque document numérique à partager, en constituant une table d'index et en mettant en correspondance, dans cette table d'index, l'identifiant d'un document et l'emplacement de ce document dans le réseau. La table d'index peut être centralisée ou distribuée. Dans le cas d'une table d'index centralisée, la table d'index permet de minimiser le temps de recherche de l'emplacement d'un document dans le réseau. Cependant, le serveur central doit être dimensionné en fonction du nombre de postes pairs connectés. En effet, plus le système est utilisé, plus les performances du serveur central doivent être importantes (réponses à des requêtes simultanées, recherche dans une base de données, ...). Une façon de réduire le coût d'un tel serveur central consiste à répartir et distribuer la table d'index sur les postes pairs eux-mêmes. Toutefois, dupliquer la table d'index centralisée sur chaque poste pair demande des ressources relativement importantes qui peuvent être, en pratique, insupportables pour de tels postes pairs. De plus, distribuer la table d'index sous-entend une mise à jour des tables locales d'index. La solution la plus triviale consisterait à informer chaque poste du réseau dès qu'un nouveau document est partagé ou qu'un poste vient de récupérer un document. Ce type de mise à jour est en pratique inconcevable car ce mécanisme encombrerait le réseau et la majeure partie des communications entre postes pairs consisterait à échanger des messages de mise à jour. La présente invention apporte une solution à ce problème. Elle porte sur un procédé de partage d'un document numérique à travers un réseau de communication, en particulier de type poste à poste, ledit procédé étant mis en oeuvre au sein d'un poste créateur dudit document à partager. Selon une définition générale de l'invention, le procédé comprend les étapes suivantes: i) obtenir au moins un identifiant dudit document à partager et/ou une représentation de celui-ci; ii) obtenir au moins une liste des postes destinataires dudit document dans le réseau; iii) obtenir au moins une liste de postes aptes à servir ledit document dans le réseau; iv) obtenir au moins une liste de postes potentiels, susceptibles de servir ledit document dans le réseau; et v) envoyer aux postes destinataires appartenant à ladite liste des postes destinataires une notification comportant une représentation du document à partager et/ou l'identifiant associé, la liste des postes aptes à 10 servir, et la liste des postes potentiels. Ainsi, dès le partage d'un document, chacun des postes appartenant à la liste des postes destinataires est informé des postes aptes à servir le document et des postes potentiellement aptes à servir ledit document. La liste des postes aptes à servir et la liste des postes potentiels définissent ainsi les postes qui sont réellement intéressés par les informations de localisation et/ou d'emplacement associées au document à partager. Les postes exclus de ces deux listes ne sont pas réellement concernés par ces informations de localisation. En pratique, les postes exclus n'accèdent jamais à ce document dans un système de partage conforme à l'invention, dans lequel l'accès au document à partager est ainsi limité et filtré par la liste des postes destinataires. Selon une réalisation, chaque poste souhaitant partager un document comprend au moins une table locale d'index contenant des informations appartenant au groupe formé par l'identifiant du document à partager, au moins une représentation dudit document à partager, le chemin d'accès audit document, au moins un identifiant d'un poste apte à servir, et au moins un identifiant d'un poste potentiel. En pratique, le procédé comprend en outre une étape de mise à jour de la table locale d'index en changeant le statut d'un poste appartenant à la liste des postes potentiels en poste apte à servir suite à la réception, en provenance d'un poste destinataire, d'un message de confirmation d'aptitude à servir le document. Selon une autre réalisation, le procédé comprend en outre l'étape d'obtention au niveau d'un poste serveur central d'une table centrale des utilisateurs contenant des informations relatives à l'enregistrement des utilisateurs, une table centrale des postes contenant des informations relatives à la connexion des postes au réseau de communication, une table centrale contenant des informations relatives aux postes destinataires et une table centrale des requêtes contenant des informations relatives aux notifications de partage. De préférence, chaque poste comprend en outre un carnet 10 d'adresses contenant des informations appartenant au groupe formé par le nom de l'utilisateur, une adresse de messagerie dans le réseau, un identifiant d'utilisateu-r-et-un-identifiant d "férence De plus, chaque poste comprend en outre une table locale des postes contenant des informations appartenant au groupe formé par l'identifiant 15 du poste, et des informations de connexion et de bande passante. Par exemple, l'obtention de l'identifiant du document à partager et/ou la représentation de celui-ci est réalisée par la table locale des index du poste. Selon un autre exemple, l'obtention de l'identifiant du document et/ou la représentation de celui-ci est réalisée auprès du poste serveur central. De son côté, l'obtention des listes de postes aptes et potentiels est réalisée par la table locale d'index du poste. En pratique, la notification comporte des informations de connexion pour un sous-ensemble choisi de postes appartenant aux listes des postes aptes et des postes potentiels. Par exemple, le sous-ensemble de postes est déterminé en fonction d'un nombre maximum prédéterminé de postes. Selon une réalisation, les postes aptes sont pris en priorité par rapport aux postes potentiels, dans le sous-ensemble de postes. Selon une autre réalisation, le sous-ensemble de postes est 30 déterminé selon un critère de bande passante et/ou de temps de présence du poste dans le réseau de communication. La présente invention a également pour objet un procédé de partage d'un document numérique à travers un réseau de communication, en particulier de type poste à poste, ledit procédé étant mis en oeuvre au sein d'un poste destinataire dudit document, caractérisé en ce qu'il comporte les étapes suivantes: 1) recevoir une notification comportant une représentation du document numérique et/ou l'identifiant de celui-ci, au moins une liste de postes aptes à servir le document et au moins une liste de postes potentiels susceptibles de servir le document numérique dans le réseau; et 2) en réponse à la notification ainsi reçue, mettre à jour une table locale d'index comportant des informations appartenant au groupe formé par l'identifiant du document à partager, au moins une représentation dudit document à partager, le chemin d'accès audit document, au moins un identifiant d'un poste apte à servir, et au moins un identifiant d'un poste potentiel. Selon une réalisation, le procédé comporte en outre, pour obtenir un document numérique, les étapes suivantes: a) à partir de la table locale d'index ainsi mise à jour, extraire les informations correspondantes au partage du document ainsi que celles des postes aptes à servir et des postes potentiels; et b) envoyer une requête d'obtention du document à destination d'au moins un poste appartenant à la liste des postes aptes à servir et à la liste des postes potentiels ainsi extraites. Selon une réalisation, la requête d'obtention est envoyée séquentiellement aux postes parmi les listes de postes aptes et de postes potentiels selon un ordre prédéterminé jusqu'à obtention du document. Selon une autre réalisation, le procédé comporte une étape de mise à jour de la table locale d'index en affectant le statut de poste potentiel aux postes destinataires de la requête d'obtention qui n'envoient pas le document en réponse à ladite requête d'obtention. En pratique, la requête d'obtention et les listes de postes aptes à servir et de postes potentiels, sont envoyés à un poste serveur central dans le cas où le document n'a pas été reçu suite à l'envoi séquentiel. Par exemple, l'ordre prédéterminé de l'envoi est défini selon un critère de bande passante et/ou de temps de présence du poste dans le réseau de communication. Selon encore une autre réalisation, le procédé comporte une étape de mise à jour de la table locale d'index suite à la réception en réponse à la requête d'obtention d'une nouvelle liste de postes serveur et d'une nouvelle liste de postes potentiels. En pratique, les nouvelles listes sont prises en compte pour l'envoi séquentiel de la requête d'obtention. En outre, le procédé comporte une étape d'envoi à destination des postes appartenant aux listes de postes aptes et de postes potentiels, d'un message de confirmation confirmant l'aptitude à servir le document numérique, suite à la réception d'une réponse à la requête d'obtention dudit document numérique. La présente invention a également pour objet un dispositif de partage pour la mise en oeuvre du et/ou des procédés selon l'invention. La présente invention a également pour objet un support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en oeuvre d'un procédé de partage selon l'invention, lorsque ce programme est chargé et exécuté par un système informatique. La présente invention a enfin pour objet un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de partage selon l'invention, lorsque ce programme est chargé et exécuté par un système informatique D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels: - la figure la représente schématiquement l'architecture générale d'un dispositif de partage conforme à l'invention, et la figure lb représente un fichier collection conforme à l'invention; - la figure 2 représente schématiquement l'architecture générale 5 d'un serveur central conforme à l'invention; - les figures 3a, 3b, 3c et 3d représentent respectivement les tables centrales des utilisateurs, des postes, des messages de notification et des requêtes d'obtention contenues dans le poste serveur central conformément à la présente invention; - les figures 4a, 4b et 4c représentent respectivement une table locale d'index, un carnet d'adresses et une table locale des postes contenus dans chaque poste pair conformément à la présente invention; - la figure 5 est un organigramme illustrant le partage d'un ensemble de documents selon l'invention; - la figure 6 est un organigramme illustrant la composition et l'envoi du message de notification destiné à chaque destinataire selon l'invention; la figure 7 est un organigramme illustrant la mise à jour de la table locale d'index suite à l'étape E510 de la figure 5; - la figure 8 est un organigramme illustrant la mise à jour de la table 20 locale d'index suite à l'étape E512 de la figure 5; - la figure 9 est un organigramme illustrant l'extraction des informations de connexion des postes aptes à servir et des postes potentiels selon l'invention; - la figure 10 est un organigramme illustrant la sélection des postes 25 aptes à servir et, le cas échéant, la sélection des postes potentiels selon l'invention; - la figure Il est un organigramme illustrant le procédé selon l'invention lors de la réception d'un message de notification par un destinataire enregistré ; - la figure 12 est un organigramme illustrant la mise à jour de la table locale d'index suite aux étapes E1110 et E1119 de la figure 11; - la figure 13 est un organigramme illustrant la mise à jour de la table locale d'index suite à la réception d'un message de notification selon l'invention - la figure 14 est un organigramme illustrant le procédé permettant 5 de demander une version d'un document partagé selon l'invention; - la figure 15 est un organigramme illustrant le procédé de connexion d'un poste local avec un poste distant selon l'invention à la suite de l'étape E1406 de la figure 14; - la figure 16 est un organigramme illustrant la mise à jour de la table 10 locale d'index à la suite de l'étape E1414 de la figure 14; - la figure 17 est un organigramme illustrant la réponse mise en oeuvre en réplique à une requête d'obtention de document émise par un poste distant selon l'invention; - la figure 18 est un organigramme illustrant la réception d'une 15 réponse suite à l'émission d'une requête; - la figure 19 est un organigramme illustrant la réception d'un message de notification émis par un poste devenu poste apte à servir selon l'invention; et - la figure 20 est un organigramme illustrant le procédé permettant 20 de ne plus servir un document partagé selon l'invention. En référence à la figure la, on a représenté sous la forme d'un diagramme blocs l'architecture générale d'un dispositif de partage de documents numériques utilisant une table d'index distribuée. Le dispositif est composé d'un poste serveur central 100 et de trois postes 101, 102 et 103. Le poste 101 est considéré par la suite comme étant le poste à partir duquel le partage d'un nouveau document est issu. Le poste 102 est considéré par la suite comme étant un poste qui reçoit une requête d'obtention mais qui ne peut servir le document demandé. Le poste 103 est considéré par la suite comme étant le poste qui émet une requête d'obtention vers le poste 101. Le poste 101 répond en servant le document demandé. Ces différentes entités sont reliées par un réseau de communication 104 tel qu'Internet. Le serveur central 100 a pour rôle de centraliser et de stocker dans des tables, les informations concernant les utilisateurs enregistrés (table centrale des utilisateurs, figure 3a) et les informations de connexion des postes connectés au système (table centrale des postes, figure 3b). De plus, le serveur central 100 stocke temporairement les messages de confirmation et/ou de notification (table centrale des messages, figure 3c) et les requêtes d'obtention (table centrale de requêtes, figure 3d). Le poste serveur central 100 est par exemple une machine du type microordinateur ou station de travail, connectée en permanence au réseau poste à poste. L'architecture d'une telle machine est décrite en référence à la figure 2. En pratique, un utilisateur qui souhaite partager un document est enregistré auprès du poste serveur central 100. Pour cela, l'utilisateur se connecte au serveur central par l'intermédiaire d'un service Web ou par l'intermédiaire d'une application graphique dédiée au système de partage.Par exemple, le poste serveur central envoie un formulaire que l'utilisateur remplit en précisant un nom de connexion ( login name en anglais), un mot de passe ( password en anglais), un moyen de lui envoyer un message de notification pour l'informer qu'un nouveau document est partagé (par exemple une adresse de messagerie ou un numéro de téléphone). De plus, un poste est attaché à cet utilisateur, appelé encore poste de référence . Un tel poste de référence peut être le moyen d'envoyer à cet utilisateur un message de notification, au lieu d'envoyer cette notification par messagerie. Le poste de référence est aussi utilisé pour envoyer les messages de confirmation. Par la suite, on considère qu'un seul poste de référence est attaché à chaque utilisateur mais plusieurs postes de référence peuvent aussi être attachés. En cas de pluralité des postes de référence, les messages de confirmation (et éventuellement de notification) sont envoyés à tous les postes ou à un poste de référence sélectionné par l'utilisateur parmi cette pluralité de postes de référence. Par exemple, les messages de notification sont envoyés à l'adresse e-mail de l'utilisateur et les messages de confirmation sont envoyés à un poste de référence. Ainsi, seuls les destinataires enregistrés reçoivent les messages de confirmation de la table locale d'index. Selon un autre exemple, lors de la procédure d'enregistrement, le serveur central enregistre le poste à partir duquel l'utilisateur est connecté, 5 comme étant son poste de référence. L'identifiant de ce poste de référence est rajouté aux informations concernant cet utilisateur. Bien évidemment, l'utilisateur peut accéder à ces informations d'enregistrement de manière à modifier, par exemple, son poste de référence, ou rajouter une adresse de messagerie. Toutes ces informations sont mémorisées dans la table centrale des utilisateurs. De plus le poste serveur central associe un identifiant unique à l'utilisateur nouvellement enregistré. Tout poste jouant le rôle de poste serveur de documents partagés, est enregistré auprès du serveur central. Cet enregistrement peut s'effectuer automatiquement, selon un mode de réalisation de l'invention, dès que le poste se connecte pour la première fois au système ou qu'un utilisateur s'enregistre auprès de la table centrale des utilisateurs. Pour s'enregistrer, le poste envoie les informations de connexion (adresse IP, port, nom d'usage...) au poste serveur central 100 qui associe un identifiant unique à ce poste. Ces informations sont mémorisées dans la table centrale des postes du poste serveur central 100 que l'on décrira plus en détail ci-après. On peut noter que la table centrale des postes est mise à jour à chaque connexion ou déconnexion d'un poste enregistré. Lorsque le poste est déconnecté, l'entrée correspondante de la table centrale des postes est conservée mais les informations de connexion ne sont plus disponibles. Dès qu'il se connecte, l'entrée de la table centrale des postes est mise à jour en incluant les nouvelles informations de connexion. Pour chaque poste ainsi enregistré, la table centrale des postes stocke également le temps moyen de connexion et la bande passante. Les postes 101,102 et 103 peuvent être par exemple un micro- ordinateur ou une station de travail. Ces appareils jouent pleinement le rôle de poste pair, à savoir le rôle de client et le rôle de serveur. L'architecture de ces postes est par exemple identique à celle du poste 100 décrite en référence à la figure 2. Cependant ces postes se différencient du poste 100 de part leurs capacités de stockage et de puissance de calcul qui peuvent être bien inférieures à celles du poste 100. Chaque poste 101,102 ou 103 maintient une table locale d'index et un carnet d'adresses décrit en détails en référence aux figures 4a et 4b. La table locale d'index permet de retrouver les identifiants des postes serveurs, c'est-à-dire les postes qui servent une version d'un document numérique et les identifiants des postes potentiels susceptibles de servir cette version. Chacun de ces postes maintient également un carnet d'adresses qui permet d'envoyer un message à un destinataire. En référence à la figure 2, on a décrit l'appareil programmable mettant en oeuvre l'invention. Cet appareil peut être le poste 100, 101, 102 ou 103. L'appareil comporte un bus de communication 209 auquel sont reliés: - une unité centrale de traitement 202 (microprocesseur), qui commande les échanges entre les divers éléments de l'appareil, - une mémoire morte 201 pouvant comporter les programmes, - une mémoire vive 205 comportant des registres 208 adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes, - un disque dur 203 pouvant comporter les programmes précités, - un lecteur de disquette 211 adapté à recevoir une disquette 210 et à y lire ou à y écrire des documents traités ou à traiter selon l'invention, - une interface de communication 206 reliée à un réseau de communication 104, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des documents. Le bus de communication 209 permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil directement ou par l'intermédiaire d'un autre élément de l'appareil. Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké par exemple dans le disque dur 203 ou en mémoire morte 201. Selon une variante de réalisation, la disquette 210 peut contenir des documents ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil, est stocké dans le disque dur 203. Selon une autre variante de réalisation, le code exécutable des 5 programmes peut être reçu par l'intermédiaire du réseau de communication 104, via l'interface 206, pour être stocké de façon identique à celle décrite précédemment. Les disquettes peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. De manière plus générale, le ou les programmes peuvent être chargés dans un des moyens de stockage de l'appareil avant d'être exécutés. L'unité centrale 202 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 203 ou la mémoire morte 201 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 203 ou la mémoire ROM 201, sont transférés dans la mémoire vive RAM 205 qui contiendra alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. II convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). On fait à nouveau référence à la figure la. Le système de partage débute par l'étape El de partage d'au moins un document (à partir du poste 101). Cette étape consiste à mettre à jour la table locale des index et à créer un fichier collection FC que l'on décrira plus en détails en référence aux figures 5 à 10. Le fichier FC (figure lb) comporte l'identifiant unique IDD de chacun des documents à partager (liste LIDD des IDD images), la liste des postes serveurs LPS de la version originale de chaque document et la liste des postes serveurs potentiels LPP de cette version. Une variante consiste à stocker également dans ce fichier collection FC les numéros de version et, pour chaque version de chaque document, la liste des postes serveurs LPS et la liste des postes serveurs potentiels LPP. Le fichier collection FC ne contient ici que les identifiants IDD des images (pas d'identifiant de version ou de représentation. En variante non représentée, le fichier collection peut également contenir des identifiants relatifs à chaque version ou représentation du document à partager. Le fichier collection peut selon une autre variante contenir également un identifiant unique de collection. On peut remarquer que la liste LD des postes destinataires (non représentée en figure lb) peut être incluse dans le fichier collection FC dans le cas où des droits d'accès sont mis en place pour restreindre l'accès à ces documents partagés. De plus, les deux listes de postes LPS et LPP peuvent ne pas être directement intégrées dans le fichier collection FC. En pratique, le message de notification comporte les identifiants des documents IDD partagés et les deux listes de postes LPP et LPS. La liste de postes serveurs LPS est une liste des identifiants de postes distants IDP qui servent une représentation, de préférence la version originale, d'un document. La liste de postes serveurs potentiels LPP est la liste des identifiants des postes distants IDP qui peuvent servir cette représentation, de préférence cette version originale. Les postes potentiels n'ont pas confirmé qu'ils servent cette version originale à la différence des postes serveurs appartenant à la liste LPS. Cette confirmation de capacité à servir est décrite plus en détails en référence à la figure 18. Par exemple, les serveurs potentiels sont au moins les postes de la liste LPR, c'est-à-dire la liste des postes de référence de chaque destinataire (au moins un poste par destinataire), qui n'ont pas encore confirmé antérieurement leur capacité à servir une version originale. Une fois que l'étape El de création est terminée, l'étape E2 envoie un message de notification à chaque destinataire (figure 6). Dans ce messagede notification, le poste 101 a inclus une liste de postes serveurs de la version originale (par exemple, son propre poste) et une liste de postes potentiels (au minimum le poste 102 et le poste 103). Ce message comporte le fichier collection et un moyen de récupérer au moins une version (la vignette) de chaque document partagé. Selon une variante, le message de notification est également envoyé au poste serveur central 100 qui devient poste serveur d'au moins une version de chaque document partagé (étape E2'). Ainsi, au moins une version de chaque document partagé est toujours disponible dans le réseau. En contrepartie, il convient de doter le poste serveur central d'espace mémoire suffisant pour stocker la version de ces documents. En pratique, on stocke la vignette de chaque document partagé sur le poste 100. Ainsi, chaque poste peut récupérer la vignette d'un document dans le cas où la copie de cette version reçue avec le message de notification est détruite. Une fois qu'un destinataire 103 a reçu cette notification, il met à jour sa table locale d'index (figures 11 et 12) et il peut visualiser les vignettes des documents nouvellement partagés. II peut également sélectionner une ou plusieurs d'entre elles et demander à récupérer une autre version de ce ou ces documents (étape E3). Par la suite, on considère que la requête ne porte que sur la version d'un seul document. En effet, dans le cas où un utilisateur sélectionne plusieurs documents et demande pour chacun d'entre eux une version, une requête est envoyée pour chacun des documents. Pour créer une requête, le système utilise la table locale d'index qui lui fournit la liste des postes serveurs LPS de la version sélectionnée et la liste des postes serveurs potentiels LPP (figures 14 à 16). Ensuite, la requête est envoyée tour à tour jusqu'à ce que l'un de ces postes puissent servir la version du document (étapes E4 et E6). On verra par la suite comment résoudre le cas où aucun de ces postes ne peut servir la version. Dès la réception d'une requête, le poste local répond en envoyant la version du document demandée (étape E7) (figure 17). Dans le cas où cette version n'est pas stockée localement, le poste extrait de sa table locale d'index, la liste des postes serveurs LPS et la liste des postes serveurs potentiels LPP correspondant à toutes les versions de ce document. Un message de réponse permettant la mise à jour est créé et envoyé au poste demandeur (étape E5). Ce message de réponse contient les deux listes d'identifiants de postes LPS et LPP (figure 17). Une fois que le poste demandeur reçoit la réponse à sa requête (figure 18) , deux cas peuvent se produirent. Si ce message contient la version du document demandé, le poste met à jour sa table locale d'index en référençant le chemin d'accès de l'entrée de la table correspondant à cette version. Il devient alors poste serveur de la version. Ensuite, ce poste envoie à chaque poste de la liste des postes serveurs LPS et à chaque poste de la liste des postes serveurs potentiels LPP, un message de confirmation les informant qu'il est serveur de la version du document qu'il vient de récupérer. Dans le cas où le poste distant ne peut être connecté, le message est stocké temporairement dans la table centrale des messages du poste 100. Ce message est délivré au poste distant dès que ce dernier se connecte. Si le message de réponse à la requête ne contient pas la version du document demandée, le statut du poste distant est modifié : si le poste distant est un poste serveur, il est supprimé de la liste des postes serveurs et rajouté à la liste des postes serveurs potentiels LPP. De plus, la table locale d'index est mise à jour selon les deux listes de poste reçues (figure 18). Bien évidemment, on évite d'envoyer deux fois la requête à un même poste. On peut remarquer que selon la réalisation préférée, aucun message de mise à jour n'est envoyé dans ce cas là. Une variante consiste à envoyer ce message aux postes des deux listes LPS et LPP pour les informer qu'un poste distant n'est plus serveur de cette version de ce document. Dans un système de partage de documents numériques, il convient de prévoir des moyens pour partager un document mais aussi des moyens pour 30 qu'un poste arrête de servir une ou plusieurs versions d'un document (figure 20), ou toutes les versions de tous les documents référencés dans un fichier collection. En pratique, trois types de messages sont envoyés: le message de notification, les messages de requête et les messages de mise à jour des tables locales d'index. Envoyer un message d'un poste à un autre dans un système poste à poste hybride ne pose aucun problème lorsque le poste destinataire est déjà connecté au poste émetteur. II en est de même pour tout message envoyé d'un poste vers le serveur central qui est accessible en permanence. Par contre, le problème d'envoi d'un message se pose lorsque le poste destinataire n'est pas accessible temporairement, car il est alors nécessaire de stocker le message et de l'envoyer à ce poste dès qu'il redevient accessible. Deux stratégies peuvent être utilisées: passive ou active. La première (passive) consiste à stocker le message sur le poste émetteur (par exemple le poste 101) et à envoyer le message au poste destinataire (par exemple le poste 102), dès que ce dernier se connecte au poste 101. Une variante de cette stratégie consiste à envoyer le message au serveur central 100, qui stocke le message jusqu'à ce que le poste 102 se connecte au serveur central 100. Le message est alors envoyé au poste 102. La seconde stratégie (active) consiste à se connecter au poste 102 et à lui envoyer le message. Comme le poste 101 ne connaît que l'identifiant de ce poste 102 (à partir de la table locale d'index TLI ou du carnet d'adresses CA), il lui faut obtenir les informations permettant de se connecter à ce poste 102 (informations de connexion). Une première sous-variante consiste à demander au serveur central ces informations de connexion, qui sont stockées dans la table centrale des postes TCP, si le poste 102 est connecté. Selon cette sous-variante et, dans le cas où le poste 102 n'est pas accessible, le message est soit stocké sur le poste 101, soit envoyé au serveur central qui le stocke. Dès que le poste 102 se connecte, il en informe le serveur central. Si le message est stocké sur le serveur central, le message est délivré au poste 102. Si le message est stocké sur le poste 101, le serveur central 100 envoie les informations de connexion du poste 102 au poste 101, qui se connecte au poste 102 pour lui envoyer le message. Une deuxième sous-variante consiste à stocker localement sur chaque poste une table locale des postes. La description de cette table est identique à celle utilisée par le serveur central 100, mais sa mise à jour est différente. En effet, seules les informations de connexion de certains postes sont stockées dans cette table, à savoir les informations de connexion des postes référencés dans la table locale des index TLI. Cette table peut être synchronisée avec la table centrale des postes du serveur central. Cependant, cette synchronisation engendre du trafic. Néanmoins, cette table locale des postes est mise à jour lorsque le poste reçoit un message. Pour cela, dès qu'un poste envoie un message contenant un identifiant de poste, il joint à ce message les informations de connexion de ce poste selon sa table locale des postes. Si l'information de connexion du poste 102 est disponible à partir de la table locale des postes, le poste 102 peut ne pas être accessible si ces informations sont obsolètes. Dans ce cas, le poste 101 demande les informations de connexion au serveur central qui lui transmet les informations à partir de la table centrale des postes TLP. Ces informations sont stockées dans la table locale des postes. Il peut arriver que le poste 102 ne soit pas accessible en raison de sa non connexion au réseau. A ce moment-là, soit le message est stocké localement sur le poste 101, soit il est stocké sur le serveur central. Dans le premier cas, dès que le poste 102 se connecte au serveur central, le serveur central en informe le poste 101 qui récupère les informations de connexion, met à jour sa table locale des postes et établit une connexion avec le poste 102 pour lui envoyer le message. Il peut arriver également que la table locale des postes soit remise à jour à partir de messages émanant d'autres postes distants. A ce moment-là, dans le cas où le message a été stocké localement, chaque fois qu'une mise à jour des informations de connexion du poste 102 est faite, le poste 101 essaie de se connecter au poste 102. En cas de succès, le message est envoyé. Si le message est stocké sur le serveur central, le message est envoyé au poste 102 dès que ce poste se connecte. Selon une réalisation, chaque poste maintient une table locale de postes (figure 4) et les messages sont stockés sur le serveur central. La table des messages contient le message et l'identifiant du poste destinataire. La table des requêtes contient la requête et une liste de postes (postes serveurs et postes serveurs potentiels) (figure 3). Cette liste est envoyée en même temps que la requête par le poste émetteur de la requête. Ainsi, dès que la table centrale des postes du serveur central est mise à jour, le serveur central teste si un message peut être délivré ou si une requête peut être servie. Dans l'affirmative, le message est envoyé et la requête est envoyée tour à tour à chaque poste connecté (envoi en boucle). Bien évidemment, dès qu'un poste a reçu la requête, il est supprimé de la liste des postes associés à la requête. Dès qu'un de ces postes a délivré le document demandé, la requête est supprimée de la table. De même, dès que la requête est envoyée à tous les postes de cette liste, la requête est supprimée de la table des requêtes. En référence à la figure 3, on a décrit l'organisation des informations stockées sur le serveur central 100. Selon une réalisation, les informations concernant les requêtes en attente de réponses, les messages de mise à jour, les informations sur les utilisateurs et les informations de connexion des postes sont centralisées sur le poste serveur central 100. En variante, l'invention peut s'appliquer à un système qui distribue ces informations (ou une partie d'entre elles) sur les postes 101,102 ou 103. Les informations stockées sur le serveur central sont groupées dans quatre tables: 1) la table centrale des utilisateurs TCU (figure 3a) ; 2) la table centrale des postes TCP (figure 3b) ; 3) la table centrale des messages TCM (figure 3c) ; et 4) la table centrale des requêtes TCR (figure 3d). La table centrale des utilisateurs TCU a pour but de stocker les 30 informations relatives à un utilisateur enregistré. Cinq champs sont renseignés: l'identifiant unique de l'utilisateur IDU, le nom de connexion, le mot de passe, l'identifiant de son poste de référence et un moyen de le joindre (e-mail ou numéro de téléphone). La table centrale des postes TCP a pour but de stocker les informations de connexion des postes connectés au système de partage. En effet, chaque poste enregistré fournit dès sa connexion son nom d'usage, son adresse IP, port,.... De plus, le serveur central est en mesure de calculer un temps de présence (de connexion) pour ce poste sur une période de temps définie. Enfin, chaque poste fournit sa bande passante. La table centrale des requêtes TCR stocke temporairement les requêtes qui ne peuvent être servies. L'identifiant de la version du document que l'on recherche, la liste des postes serveurs et la liste des postes serveurs potentiels associées au document demandé correspondent à une entrée de la table centrale des requêtes. Ainsi, dès qu'un nouveau poste se connecte au serveur central, ce dernier teste si la requête peut être servie par ce poste. La table centrale des messages TCM de mise à jour. La mise à jour de la table locale d'index TLI nécessite l'envoi de messages de mise à jour à certains postes distants. Un message est stocké dans la table locale d'index lorsqu'un poste n'est pas connecté au réseau, dès lors que ce message doit lui être envoyé. Dès que le poste destinataire de ce message se connecte au serveur central, le message de mise à jour lui est adressé. En référence à la figure 4, on a décrit l'organisation des informations stockées sur les postes 101, 102 et 103. La table locale d'index TLI est vide au démarrage du système. La table TLI comporte plusieurs entrées, chacune d'entre elles stockant des informations correspondant à une version d'un document partagé. Chaque entrée est composée de cinq champs: 1) l'identifiant unique du document partagé (IDD) ; 2) le numéro de version du document partagé (IDV) ; 3) le chemin d'accès local permettant d'accéder à une version d'un 30 document (CHA) ; 4) la liste d'identifiants de postes qui servent la version du document (IDPS) ; et 5) la liste d'identifiants de postes qui peuvent servir la version du document (IDPP). Deux identifiants sont associés à chaque version de chaque document partagé : un unique IDD pour identifier le document et un autre IDV pour identifier la version de ce document (version originale, vignette,...). L'identifiant IDV est un numéro précisant une version (résolution, qualité visuelle). Par la suite, on considère que V (nombre entier) versions sont accessibles pour chaque document partagé. Le carnet d'adresses CA est une table dans laquelle sont stockés les moyens d'identifier un destinataire. On rappelle que les destinataires ne sont pas forcément enregistrés pour pouvoir recevoir une donnée partagée. Dans ce cas, le carnet d'adresses CA ne comporte que le nom d'usage NOU et au moins un moyen d'envoyer un message au destinataire (e-mail, numéro de téléphone). Dans le cas où le destinataire est enregistré, l'identifiant de l'utilisateur IDU et au moins un poste de référence IDPR sont également stockés. La table locale des postes TLP a pour but de stocker les informations de connexion des postes référencés dans la table locale d'index TLI. En référence à la figure 5, on a décrit le procédé de partage d'un ensemble de documents numériques. Le procédé débute par la création d'un nouveau fichier collection décrit en référence à la figure 1 b. Le fichier FC contient les identifiants IDD des D (nombre entier) documents à partager et, pour chacun d'entre eux, la liste des identifiants des postes qui servent la version originale du document et la liste des identifiants des postes qui peuvent servir la version originale de ce document. Au cours de l'étape E500, l'utilisateur sélectionne D (D nombre entier) documents à partager et K (nombre entier) destinataires à partir de son carnet d'adresses CA. Les étapes E501 à E507 permettent de créer la liste LD des postes de référence des destinataires enregistrés. Dans le cas où les informations concernant un destinataire ne sont pas présentes (ou incomplètes) dans le carnet d'adresses CA, le poste demande ces informations auprès du poste serveur central 100 qui lui répond si le destinataire est enregistré et, dans ce cas, lui envoie son identifiant IDU et l'identifiant de son poste de référence IDPR. Ensuite, pour chaque document (E508), l'étape E509 teste si le document est déjà partagé. Pour cela, le procédé s'appuie sur le moyen de sélectionner le document à partager. En effet, l'utilisateur sélectionne le document à partir d'une interface graphique. Cette interface permet de visualiser les vignettes des documents déjà partagés et les documents stockés localement et qui ne sont pas partagés. Ainsi, si la sélection porte sur une vignette, le procédé sait que ce document est déjà partagé au travers de sa table locale d'index TLI, qui référence le chemin d'accès de cette version. Dans le cas où le document est déjà partagé, une entrée de la table locale d'index TLI est sélectionnée. L'étape E510 récupère l'identifiant IDD du document à partir de cette entrée. L'étape E511 met à jour la table locale d'index selon la figure 7. Le traitement du document s'arrête à la suite de l'étape E514. Dans le cas où le document n'est pas déjà partagé, un nouvel identifiant est généré. Selon une réalisation, cet identifiant est créé par le poste local. Une variante consiste à demander un identifiant au poste 100. L'étape 20 E513 met à jour la table locale d'index selon la figure 8. Le procédé de la figure 5 se poursuit par l'étape E515 (figure 6) dans le cas où le test de l'étape E514 est positif (tous les documents à partager sont traités). En référence à la figure 6, on a décrit la suite du procédé de partage d'un ensemble de documents de la figure 5. Cette figure 6 décrit la composition et l'envoi du message de notification à chacun des K destinataires. Les étapes E517 à E524 décrivent le traitement pour un document. L'étape E517 ajoute la vignette au fichier collection FC. L'étape E518 sélectionne l'entrée de la table locale d'index correspondant à la version originale V du document courant. Les étapes E519 et E520 extraient et ajoutent au fichier collection FC la liste des postes serveurs LPS correspondant à cette entrée, c'est-à-dire la liste des postes qui servent la version originale du document courant (par exemple le poste initiateur, s'il contient les données). L'étape E521 teste si la version originale du document est stockée localement (chemin d'accès référencé de l'entrée sélectionnée). Dans l'affirmative, l'identifiant IDD du poste local est ajouté à la liste des postes serveurs extraite. Le procédé selon les étapes E523 et E524 extrait et ajoute au fichier collection la liste des postes serveurs potentiels LPP correspondant à cette entrée, c'est-à-dire la liste des postes qui peuvent servir la version originale du document courant. Au minimum, cette liste comporte les postes de la liste LPR, c'est-à-dire les postes destinataires de la notification puisqu'ils sont susceptibles d'avoir la version ultérieurement. Le procédé selon l'étape E527 crée une liste L composée des identifiants des deux listes extraites (postes serveurs et postes serveurs potentiels). Pour cela, chacune de ces deux listes LPS et LPP est ordonnée de façon décroissante selon la présence et/ou la bande passante de chacun des postes (informations extraites de la table locale des postes). Le procédé selon l'étape E528 extrait et ajoute les informations de connexion des postes de la liste ainsi constituée au fichier collection FC (figure 9). Selon une autre variante, ces informations ne sont pas intégrées dans le fichier collection FC, mais sont stockées dans le message de notification envoyé au destinataire lors de l'étape E529. Dans le cas où les informations concernant un destinataire sont incomplètes (absentes du carnet d'adresses CA), le poste demande ces informations auprès du serveur central qui lui répond l'identifiant de ce destinataire et l'identifiant de son poste de référence dans le cas où ce destinataire est enregistré. Les informations récupérées sont stockées dans le carnet d'adresses CA. En référence à la figure 7, on a décrit la mise à jour de la table locale d'index TLI à la suite de l'étape E510. L'étape E700 considère les V entrées de la table correspondant à l'identifiant du document à partager. Le procédé selon l'étape E702 ajoute la liste LPR (liste des postes de référence des destinataires) à la liste des postes serveurs potentiels LPP de l'entrée courante et ce, pour chacune des V entrées de la table locale d'index. La mise à jour se termine lorsque toutes les entrées correspondant à l'identifiant IDD du document sont traitées. En référence à la figure 8, on a décrit la mise à jour de la table locale d'index TLI suite à l'étape E512. Le procédé selon l'étape E800 crée V nouvelles entrées dans la table locale d'index. V correspond au nombre de versions accessibles de chaque document partagé. Les étapes E801 à E809 décrivent le traitement appliqué à chacune de ces entrées. Les étapes E802 et E803 ajoutent l'identifiant IDD du document courant et le numéro de version courante à l'entrée courante. L'étape E804 est similaire à celle décrite par la figure 7 (étape E702). Dans le cas où la version courante n'est pas stockée localement (E805), la version du document est créée et stockée localement et le chemin d'accès de l'entrée courante est référencé. La mise à jour de la table TLI s'arrête lorsque toutes les versions sont traitées (E808). En référence à la figure 9, on a décrit le procédé relatif à l'étape E528 de la figure 6, permettant d'extraire les informations de connexion de S (nombre entier) postes serveurs de la liste LPS et de P (nombre entier) postes potentiels de la liste LPP. Le nombre de postes de la liste des postes serveurs et des postes serveurs potentiels peut être très élevé. Afin d'éviter que la taille des messages ne soit trop importante, toutes les informations de connexion de ces postes ne sont pas envoyées. Par contre, tous les identifiants des postes sont envoyés. Si le nombre de postes serveurs (S) et le nombre de postes serveurs potentiels (P) est trop important (supérieur à un seuil Max (nombre entier)), seules les informations de connexion des SI (nombre entier) premiers postes serveurs et des P1 (nombre entier) premiers postes serveurs potentiels sont envoyées (la sélection est effectuée à l'étape E901 décrite par la figure 10). Quoi qu'il en soit, à l'étape E903, les informations des SI postes serveurs et des P1 postes serveurs potentiels sont envoyées. Les étapes E903 à E907 traitent les SI postes serveurs. Pour chaque poste, le procédé cherche à récupérer les informations de connexion du poste courant à partir de la table locale des postes. Selon une variante, cette information peut être récupérée à partir de la table centrale des postes du serveur central (poste 100). Dans ce cas, une fois récupérée, la table locale des postes est mise à jour. Le procédé selon l'étape E905 teste si l'information de connexion a pu être obtenue. Dans l'affirmative, c'est-à-dire si le poste distant est connecté, ces informations sont ajoutées au message de notification. Les étapes E909 à E914 traitent les P1 postes serveurs potentiels. Pour chaque poste, le procédé cherche à récupérer les informations de connexion du poste courant de façon similaire à celle décrite précédemment. En référence à la figure 10, on a décrit le procédé de sélection de SI postes serveurs selon une liste de S postes serveurs et de P1 postes serveurs potentiels selon une liste de P postes. L'étape E1000 teste si le nombre de postes serveurs est supérieur à un seuil Max. Dans l'affirmative, les Max premiers postes de la liste des postes serveurs sont considérés. Aucun poste serveur potentiel n'est considéré (E1001). Dans la négative, tous les postes serveurs sont considérés et Max-SI postes serveurs sont considérés (E1002). Pour pouvoir considérer un nombre restreint de postes parmi un ensemble, les critères de présence et de bande passante sont utilisés. Les postes qui sont retenus sont les postes dont la bande passante est la plus élevée et dans un deuxième temps ceux qui ont un temps de présence le plus élevé (E1003 et E1004). En référence à la figure 11, on a décrit le procédé de partage mis en oeuvre lors de la réception d'un message de notification par un destinataire enregistré. Un message de notification est envoyé à chaque destinataire par l'intermédiaire d'une messagerie. Par exemple, le fichier collection FC est un attachement au message. Dans ce cas, lorsque l'utilisateur clique sur cette pièce jointe, le procédé extrait le nombre de documents partagés (El 100). Les autres étapes de la figure 11 décrivent le traitement effectué sur le poste local du destinataire par rapport aux informations concernant chacun de ces documents. L'étape E1102 extrait et stocke localement la vignette. L'étape E1103 récupère l'identifiant IDD du document et le nombre de postes serveurs (E1104) correspondant à la version originale de ce document (version V). Pour chacun de ces postes serveurs, l'information de connexion est récupérée (E1107) et la table locale des postes est mise à jour (E1108). La table locale d'index est mise à jour selon la figure 12 en considérant V=K (version originale). Les étapes E1113 à 1119 décrivent le même procédé pour la liste des postes serveurs potentiels. Une fois que le test de l'étape E1122 est positif, le procédé continue par l'étape E1801 de la figure 18 de manière à envoyer un message de confirmation aux destinataires. En référence à la figure 12 on a décrit le procédé de mise à jour de la table locale d'index suite à la réception d'un message de notification (E1109 ou E1118). L'étape E1200 teste si l'entrée de la table locale d'index correspondante à la version courante du document courant existe. Dans la négative, une nouvelle entrée est créée selon la figure 13. Dans l'affirmative, l'étape E1201 teste si ce poste est serveur de la version originale V. Dans l'affirmative, l'identifiant de ce poste est supprimé de la liste des postes serveurs potentiels (si elle était dans cette liste, bien sûr) (E1202 et 1203). L'identifiant du poste courant est ajouté à la liste des postes serveurs de l'entrée courante s'il n'est pas déjà présent (E1204 et E1205). Le procédé selon l'étape E1206 vérifie si le poste courant est serveur potentiel de la version originale. Dans l'affirmative, l'étape E1207 teste si le poste courant est dans la liste des postes serveurs. Dans la négative, l'identifiant du poste courant est ajouté à la liste des postes serveurs potentiels de l'entrée courante s'il n'est pas déjà présent (E1208 et E1209). En référence à la figure 13, on a décrit le procédé de mise à jour de la table locale d'index suite à la réception d'un message de notification (E1200, c'est-à-dire lorsque le poste local reçoit un message de notification contenant des nouveaux documents qui ne sont pas référencés dans la table locale du poste local). La figure 13 décrit le traitement de chacune des V entrées créées dans la table locale d'index. L'étape E1300 considère la première entrée de cette table. Elle correspond à la vignette du document courant. Les étapes E1301 et E1302 créent une nouvelle entrée et ajoutent l'identifiant IDD du document et le numéro de version à cette entrée courante. L'étape E1303 teste si l'entrée courante correspond à la version originale V. Dans l'affirmative, l'étape E1304 teste si le poste courant est serveur de la version courante. Si c'est le cas, l'étape E1305 ajoute l'identifiant IDD du document à la liste des postes serveurs LPS de l'entrée courante. Si le poste courant est serveur potentiel, il est ajouté à la liste des postes serveurs potentiels LPP de l'entrée courante (E1306, E1307). Dans le cas du traitement de la première entrée, le chemin d'accès de cette entrée est référencé car le message de notification contient la vignette de chaque document partagé (E1309). Suite à la réception d'une notification et à la mise à jour de sa table d'index comme décrit précédemment en référence à la figure 11, le poste destinataire peut demander une version qu'il ne possède pas, d'un document partagé. Pour cela, il met en oeuvre un procédé permettant de demander une version d'un document partagé décrit en référence à la figure 14. L'étape E1400 sélectionne l'entrée de la table locale d'index selon l'identifiant IDD du document et du numéro de version sélectionnés. L'étape E1401extrait la liste LPS des S postes serveurs et la liste LPP des P postes serveurs potentiels de l'entrée ainsi sélectionnée. Le procédé selon l'étape E1402 crée une liste des identifiants des deux listes extraites (postes serveurs et postes serveurs potentiels). Pour cela, chacune de ces deux listes LPS et LPP est ordonnée de façon décroissante selon la présence et/ou la bande passante de chacun des postes (informations extraites de la table locale des postes). L'étape E1403 crée une requête en insérant l'identifiant IDD du document et le numéro de version. Les étapes E1405 à E1416 envoient la requête à un poste distant selon les informations de la table locale d'index et la table locale des postes. Chaque poste de la liste ordonnée est considéré. La connexion avec ce poste est testée à l'étape E1406 (figure 15). Si une connexion peut être établie avec le poste distant courant, la requête est envoyée à ce poste. Si ce poste envoie en réponse la version du document demandée, le procédé continue par l'étape E1801 de la figure 18. On voit lors de la description de la figure 17, que lorsqu'un poste distant ne peut pas servir une version d'un document, il envoie en réponse une liste de postes serveurs LPS et une liste de postes serveurs potentiels LPP du document, quelle que soit la version. Dans ce cas, ce poste distant est supprimé de la liste des postes serveurs LPP et ajouté à la liste des postes serveurs potentiels (changement de statut du poste distant). De plus, les identifiants de ces postes sont stockés dans une liste de réponses créée en prévision par l'étape E1404. Une variante consiste à tester les postes serveurs et les postes serveurs potentiels au fur et à mesure qu'ils sont reçus. L'étape E1411 considère la liste contenant toutes les réponses des postes distants qui sont peut être connectés: S2 (nombre entier) postes serveurs et P2 (nombre entier) postes serveurs potentiels. Si cette liste est vide, la requête est envoyée au poste 100 (serveur central) qui mémorise cette requête (identifiant IDD du document, numéro de version, liste des postes serveurs LPS et serveurs potentiels LPP de la table locale d'index). Cette requête est servie dès qu'un de ces postes se connecte. Pour cela, chaque fois qu'un poste se connecte au serveur central, le poste 100 évalue si une des requêtes stockées dans la table des requêtes peut être honorée. Si c'est le cas la requête est envoyée au poste distant qui répond au serveur central. Si ce poste peut servir la version du document, le serveur central stocke cette version jusqu'à ce que le poste demandeur soit connecté et la requête est supprimée de la table des requêtes. Si le poste distant répond une liste de postes serveurs LPS et une liste de postes serveurs potentiels LPP, ces deux listes sont envoyées au poste demandeur par l'intermédiaire du serveur central et le poste demandeur retombe dans le cas de l'étape E1414 qui met à jour la table locale d'index selon la figure 16. En référence à la figure 15, on a décrit le procédé de connexion d'un poste local avec un poste distant, correspondant à l'étape E1406 de la figure 14. L'étape E1500 teste si les informations du poste distant sont disponibles à partir de la table locale des postes. Si ces informations ne sont pas présentes, le procédé s'arrête. Dans l'affirmative, le procédé selon l'étape E1501 récupère ces informations et essaie de ce connecter au poste distant (E1502). Si les informations de connexion sont obsolètes (et donc que la connexion ne peut être établie), les informations de connexion du poste distant sont supprimées de la table locale des postes (E1503). En référence à la figure 16, on a décrit le procédé de mise à jour de la table locale d'index suite à l'étape E1414. La figure 16 décrit le traitement de chacune des V entrées correspondant à un document. L'étape E1600 considère une entrée de cette table. L'étape E1601 teste si le poste courant est serveur de la version courante du document. Si c'est le cas, l'étape E1602 teste si l'identifiant IDP de ce poste est contenu dans la liste des postes serveurs potentiels LPP. Si c'est le cas, l'étape E1603 supprime cet identifiant de cette liste. L'étape E1604 teste si le poste courant est contenu dans la liste des postes serveurs LPS de l'entrée courante. Si ce n'est pas le cas, l'étape E1605 ajoute l'identifiant IDP du poste courant dans la liste des postes serveurs LPS. L'étape E1606 teste si le poste courant est serveur potentiel de la version courante du document. Si c'est le cas, l'étape E1607 teste si l'identifiant IDP de ce poste est contenu dans la liste des postes serveurs LPS. Si ce n'est pas le cas, l'étape E1608 teste si le poste courant est contenu dans la liste des postes serveurs potentiels LPP. Si ce n'est pas le cas, l'étape E1609 ajoute l'identifiant IDP du poste courant à la liste des postes serveurs potentiels LPP de l'entrée courante. En référence à la figure 17, on a décrit la réponse mise en oeuvre en référence à une requête émise par un poste distant. L'étape E1700 extrait l'identifiant IDD du document et le numéro de version demandée. Le poste local (qui vient de recevoir une requête) teste si cette version peut être servie. Dans l'affirmative, c'est-à-dire que la table locale d'index de ce poste contient une entrée correspondant à cette version et que le chemin d'accès de cette entrée est référencé, le poste sert la version. Dans la négative, l'étape E1702 crée un message de réponse et les V entrées de la table locale d'index de ce poste sont sélectionnées (E1702, E1703). Le procédé selon l'étape E1704 considère l'entrée courante V2. L'entrée VI (vignette) n'est pas considérée. L'étape E1705 extrait l'entrée courante de la table locale d'index. L'étape E1706 extrait la liste des S postes serveurs de cette entrée. L'étape El 707 teste si la version du document correspondant à l'entrée courante peut être servie (chemin d'accès référencé). Si c'est le cas, l'identifiant IDP du poste local est ajouté à la liste des postes serveurs extraite. L'étape E1709 extrait la liste des P postes serveurs potentiels de l'entrée courante. L'étape E1710 ajoute les deux listes au message de réponse. L'étape E1711 extrait les informations de connexion de chacun des postes de ces deux listes et ajoute ces informations au message de réponse (figure 9). L'étape E1714 envoie le message au poste demandeur une fois que toutes les entrées sélectionnées ont été considérées. En référence à la figure 18, on a décrit le procédé de réception d'une réponse suite à l'émission d'une requête d'obtention de document correspondant à l'étape E1410 de la figure 14 et à l'étape E1122 de la figure 11. Le procédé selon l'étape E1800 teste si la réponse est la version du document demandée. Si ce n'est pas le cas, les listes de postes serveurs et de postes serveurs potentiels correspondant à chaque version de ce document sont extraites du message et les nouveaux postes serveurs et postes potentiels sont mis à jour dans la table locale d'index à l'étape E1414 de la figure 14. Si la version du document a été obtenue, l'étape E1801 stocke cette version. L'étape E1802 extrait l'entrée de la table locale d'index correspondant à cette version. L'étape E1803 supprime l'identifiant IDP du poste local de la liste des postes serveurs potentiels et ajoute le chemin d'accès de l'entrée extraite (E1804). Les étapes E1805 à E1813 envoient un message de confirmation de capacité à servir la version considérée à chacun des postes référencés par cette entrée. L'étape El 805 crée le message de confirmation. Ainsi, le poste confirme qu'il est bien devenu serveur de la version. L'étape E1806 extrait la liste des S postes serveurs et la liste des P postes serveurs potentiels de l'entrée courante. L'étape E1807 ajoute l'identifiant IDP du poste local, l'identifiant IDD du document et le numéro de version au message. L'étape E1808 considère le premier poste de la liste des postes (postes serveurs et postes serveurs potentiels). L'étape E1809 essaie de se connecter au poste courant selon la figure 15. Si la connexion ne peut s'établir le message est envoyé au poste 100 qui stocke le message dans la table des messages. Le message sera envoyé au poste destinataire lorsque celui-ci se connectera au serveur central. Si la connexion a pu s'établir, le message est envoyé. En référence à la figure 19, on a décrit le procédé de réception d'un message de confirmation émis par un poste devenu serveur. Les étapes E1900 et E1901 extraient l'identifiant IDD du document, le numéro de version et l'identifiant IDP du poste émetteur à partir du message. L'étape E1903 met à jour la table locale d'index du poste local selon la figure 12 en considérant que le poste émetteur est serveur. En référence à la figure 20, on a décrit le procédé permettant de ne plus servir un document ou un ensemble de documents (par exemple une collection) partagés. Ce procédé est initié par l'utilisateur au travers d'une interface graphique non décrite ici. Dans ce cas, le poste local n'envoie pas de message aux postes destinataires. Ces postes sont informés du changement de statut du poste local lorsqu'ils demandent la version du document et que le poste local leur envoie en réponse les listes des postes serveurs et serveurs potentiels. L'étape E2000 considère la première version du document. L'étape E2001 extrait l'entrée correspondante de la table locale d'index. L'étape E2002 retire le chemin d'accès de cette entrée. L'étape E2003 extrait la liste des postes potentiels LPP de l'entrée courante et ajoute l'identifiant IDP du poste local à cette liste (E2004). REVENDICATIONS 1. Procédé de partage d'un document numérique à travers un réseau de communication, en particulier de type poste à poste, ledit procédé étant mis en oeuvre au sein d'un poste créateur de document, caractérisé en ce qu'il comporte les étapes suivantes: i) obtenir au moins un identifiant (IDD) dudit document à partager et/ou une représentation de celui-ci; ii) obtenir au moins une liste (LD) des postes destinataires dudit document dans le réseau; iii) obtenir au moins une liste de postes (LPS) aptes à servir ledit document dans le réseau; iv) obtenir au moins une liste de postes potentiels (LPP), susceptibles de servir ledit document dans le réseau; et v) envoyer aux postes destinataires appartenant à la liste (LD) des postes destinataires une notification comportant une représentation du document numérique et/ou l'identifiant associé, la liste des postes (LPS) aptes à servir, et la liste des postes potentiels (LPP). 2. Procédé selon la revendication 1, caractérisé en ce que chaque poste souhaitant partager un document comprend au moins une table locale d'index (TLI) contenant des informations appartenant au groupe formé par l'identifiant (IDD) du document à partager, au moins une représentation (IDV) dudit document à partager, le chemin d'accès (CHA) audit document, au moins un identifiant d'un poste apte à servir (IDPS), et au moins un identifiant d'un poste potentiel (IDPP). 3. Procédé selon la revendication 2, caractérisé en ce qu'il comprend en outre une étape de mise à jour de la table locale d'index (TLI) en changeant le statut d'un poste appartenant à la liste des postes potentiels (LPP) en poste apte à servir suite à la réception, en provenance d'un poste destinataire, d'un message de confirmation d'aptitude à servir le document. 4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il comprend en outre l'étape d'obtention au niveau d'un poste serveur central d'une table centrale des utilisateurs (TCU) contenant des informations relatives à l'enregistrement des utilisateurs, une table centrale des postes (TCP) contenant des informations relatives à la connexion des postes au réseau de communication, une table centrale (TCM) contenant des informations relatives aux postes destinataires et une table centrale des requêtes (TCR) contenant des informations relatives aux notifications de partage. 5. Procédé selon l'une des revendications 2 à 4, caractérisé en ce que chaque poste comprend en outre un carnet d'adresses (CA) contenant des informations appartenant au groupe formé par le nom de l'utilisateur (NOU) , une adresse de messagerie (EMA) dans le réseau, un identifiant d'utilisateur (IDU) et un identifiant d'un poste de référence (IDPR). 6. Procédé selon l'une des revendications 2 à 5, caractérisé en ce que chaque poste comprend en outre une table locale des postes (TLP) contenant des informations appartenant au groupe formé par l'identifiant du poste (IDP), et des informations de connexion et de bande passante. 7. Procédé selon la revendication 2, caractérisé en ce que l'obtention de l'identifiant (IDD) du document à partager et/ou la représentation de celui-ci est réalisée par la table locale des index (TU) du poste. 8. Procédé selon la revendication 4, caractérisé en ce que l'obtention de l'identifiant (IDD) du document et/ou la représentation de celui-ci est réalisée 30 auprès du poste serveur central. 9. Procédé selon la revendication 2, caractérisé en ce que l'obtention des listes de postes aptes et potentiels (LPS et LPP) est réalisée par la table locale des index (TLI) du poste. 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que la notification comporte des informations de connexion pour un sous-ensemble choisi de postes appartenant aux listes des postes aptes et des postes potentiels (LPS et LPP). 11. Procédé selon la revendication 10, caractérisé en ce que le sousensemble de postes est déterminé en fonction d'un nombre maximum prédéterminé de postes. 12. Procédé selon la revendication 10, caractérisé en ce que les postes aptes sont pris en priorité par rapport aux postes potentiels, dans le sous-ensemble de postes. 13. Procédé selon la revendication 10, caractérisé en ce que le sousensemble de postes est déterminé selon un critère de bande passante 20 et/ou de temps de présence du poste dans le réseau de communication. 14. Procédé de partage d'un document numérique à travers un réseau de communication, en particulier de type poste à poste, ledit procédé étant mis en oeuvre au sein d'un poste destinataire dudit document, caractérisé en ce qu'il comporte les étapes suivantes: 1) recevoir une notification comportant une représentation du document numérique et/ou l'identifiant (IDD) de celui-ci, au moins une liste (LPS) de postes aptes à servir le document et au moins une liste (LPP) de postes potentiels susceptibles de servir le document numérique dans le réseau; et 2) en réponse à la notification ainsi reçue, mettre à jour une table locale d'index (TLI) comportant des informations appartenant au groupe formé par l'identifiant (IDD) du document à partager, au moins une représentation dudit document à partager, le chemin d'accès (CHA) audit document, au moins un identifiant d'un poste apte à servir (IDPS), et au moins un identifiant d'un poste potentiel (IDPP). 15. Procédé de partage selon la revendication 14, caractérisé en ce qu'il comporte en outre pour obtenir un document numérique les étapes suivantes: a) à partir de la table locale d'index (TLI) ainsi mise à jour, extraire 10 les informations correspondantes au partage du document ainsi que celles des postes aptes à servir et des postes potentiels; et b) envoyer une requête d'obtention du document à destination d'au moins un poste appartenant à la liste des postes aptes à servir (LPS) et à la liste des postes potentiels (LPP) ainsi extraites. 16. Procédé selon la revendication 15, caractérisé en ce que la requête est envoyée séquentiellement aux postes parmi les listes de postes aptes (LPS) et de postes potentiels (LPP) selon un ordre prédéterminé jusqu'à obtention du document. 17. Procédé selon la revendication 16, caractérisé en ce qu'il comporte une étape de mise à jour de la table locale d'index (TLI) en affectant le statut de poste potentiel aux postes destinataires de la requête d'obtention qui n'envoient pas le document en réponse à ladite requête d'obtention. 18. Procédé selon la revendication 16, caractérisé en ce que la requête d'obtention et les listes de postes aptes à servir (LPS) et de postes potentiels (LPP), sont envoyées à un poste serveur central dans le cas où le document n'a pas été reçu suite à l'envoi séquentiel de la requête d'obtention. 19. Procédé selon la revendication 16, caractérisé en ce que l'ordre prédéterminé de l'envoi est défini selon un critère de bande passante et/ou de temps de présence du poste dans le réseau de communication. 20. Procédé selon la revendication 16, caractérisé en ce qu'il comporte une étape de mise à jour de la table locale des index (TLI) suite à la réception en réponse à la requête d'obtention d'une nouvelle liste de postes serveur et d'une nouvelle liste de postes potentiels. 21. Procédé selon la revendication 20, caractérisé en ce que les nouvelles listes sont prises en compte pour l'envoi séquentielle de la requête d'obtention. 22. Procédé selon l'une quelconque des revendications 16 à 21, caractérisé en ce qu'il comporte une étape d'envoi à destination des postes des listes de postes aptes (LPS) et de postes potentiels (LPP), d'un message de confirmation confirmant l'aptitude à servir le document numérique, suite à la réception d'une réponse à la requête d'obtention dudit document numérique. 23. Dispositif de partage d'un document numérique à travers un réseau de communication, en particulier de type poste à poste, ledit dispositif étant intégré au sein d'un poste créateur de document, caractérisé en ce qu'il comprend: - des moyens pour obtenir au moins un identifiant (IDD) dudit 25 document à partager et/ou une représentation de celui-ci; - des moyens pour obtenir au moins une liste des postes (LD) destinataires dudit document dans le réseau; - des moyens pour obtenir au moins une liste de postes (LPS) aptes à servir ledit document dans le réseau; - des moyens pour obtenir au moins une liste (LPP) de postes potentiels, susceptibles de servir ledit document dans le réseau; et - des moyens pour envoyer aux postes destinataires appartenant à la liste (LD) des postes destinataires une notification comportant une représentation du document numérique et/ou l'identifiant associé, la liste (LPS) des postes aptes à servir, et la liste (LPP) des postes potentiels. 24. Dispositif selon la revendication 23, caractérisé en ce que chaque poste souhaitant partager un document comprend au moins une table locale d'index (TLI) contenant des informations appartenant au groupe formé par l'identifiant (IDD) du document à partager, au moins une représentation (IDV) dudit document à partager, le chemin d'accès (CHA) audit document, au moins un identifiant d'un poste apte à servir (IDPS), et au moins un identifiant d'un poste potentiel (IDPP). 25. Dispositif selon la revendication 24, caractérisé en ce qu'il comprend en outre des moyens de mise à jour de la table locale d'index (TL!) en changeant le statut d'un poste appartenant à la liste des postes potentiels (LPP) en poste apte à servir suite à la réception, en provenance d'un poste destinataire, d'un message de confirmation d'aptitude à servir le document. 26. Dispositif selon l'une des revendications 23 à 25, caractérisé en ce qu'il comprend en outre des moyens d'obtention au niveau d'un poste serveur central d'une table centrale des utilisateurs (TCU) contenant des informations relatives à l'enregistrement des utilisateurs, une table centrale des postes (TCP) contenant des informations relatives à la connexion des postes au réseau de communication, une table centrale (TCM) contenant des informations relatives aux postes destinataires et une table centrale des requêtes (TCR) contenant des informations relatives aux notifications de partage. 27. Dispositif selon l'une des revendications 24 à 26, caractérisé en ce que chaque poste comprend en outre un carnet d'adresses (CA) contenant des informations appartenant au groupe formé par le nom de l'utilisateur (NOU), une adresse de messagerie (EMA) dans le réseau, un identifiant d'utilisateur (IDU) et un identifiant d'un poste de référence (IDPR). 28. Dispositif selon l'une des revendications 24 à 27, caractérisé en ce que chaque poste comprend en outre une table locale des postes (TLP) contenant des informations appartenant au groupe formé par l'identifiant du poste (IDP), et des informations de connexion et de bande passante. 29. Dispositif selon la revendication 24, caractérisé en ce que les 10 moyens d'obtention de l'identifiant (IDD) du document à partager et/ou la représentation de celui-ci sont formés par la table locale des index (TLI) du poste. 30. Dispositif selon la revendication 26, caractérisé en ce que les 15 moyens d'obtention de l'identifiant (IDD) du document et/ou la représentation de celui-ci sont formés par le poste serveur central. 31. Dispositif selon la revendication 24, caractérisé en ce que les moyens d'obtention des listes de postes aptes et potentiels (LPS et LPP) sont 20 formés par la table locale des index (TLI) du poste. 32. Dispositif selon l'une quelconque des revendications 23 à 31, caractérisé en ce que la notification comporte des informations de connexion pour un sous-ensemble choisi de postes appartenant aux listes des postes aptes et des postes potentiels (LPS et LPP). 33. Dispositif selon la revendication 32, caractérisé en ce que le sousensemble de postes est déterminé en fonction d'un nombre maximum prédéterminé de postes. 34. Dispositif selon la revendication 32, caractérisé en ce que les postes aptes sont pris en priorité par rapport aux postes potentiels, dans le sous-ensemble de postes. 35. Dispositif selon la revendication 32, caractérisé en ce que le sousensemble de postes est déterminé selon un critère de bande passante et/ou de temps de présence du poste dans le réseau de communication. 36. Dispositif de partage d'un document numérique à travers un réseau de communication, en particulier de type poste à poste, ledit dispositif étant intégré au sein d'un poste destinataire dudit document, caractérisé en ce qu'il comporte: - des moyens de réception aptes à recevoir une notification comportant une représentation du document numérique et/ou l'identifiant (IDD) de celui-ci, au moins une liste (LPS) de postes aptes à servir le document et au moins une liste (LPP) de postes potentiels susceptibles de servir le document numérique dans le réseau; et - des moyens aptes, en réponse à la notification ainsi reçue, à mettre à jour une table locale d'index (TLI) comportant des informations appartenant au groupe formé par l'identifiant (IDD) du document à partager, au moins une représentation dudit document à partager, le chemin d'accès (CHA) audit document, au moins un identifiant d'un poste apte à servir (IDPS), et au moins un identifiant d'un poste potentiel (IDPP). 37. Dispositif de partage selon la revendication 36, caractérisé en ce qu'il comporte en outre pour obtenir un document numérique: - des moyens aptes, à partir de la table locale d'index (TLI) ainsi mise à jour, à extraire les informations correspondantes au partage du document ainsi que celles des postes aptes à servir et des postes potentiels; et - des moyens d'émission aptes à envoyer une requête d'obtention du document à destination d'au moins un poste appartenant à la liste des postes aptes à servir (LPS) et à la liste des postes potentiels (LPP) ainsi extraites. 38. Dispositif selon la revendication 37, caractérisé en ce qu'il comporte des moyens aptes à envoyer la requête est séquentiellement aux postes parmi les listes de postes aptes (LPS) et de postes potentiels (LPP) selon un ordre prédéterminé jusqu'à obtention du document. 39. Dispositif selon la revendication 38, caractérisé en ce qu'il comporte des moyens de mise à jour de la table locale d'index (TLI) en affectant le statut de poste potentiel aux postes destinataires de la requête d'obtention qui n'envoient pas le document en réponse à ladite requête d'obtention. 40. Dispositif selon la revendication 38, caractérisé en ce que la requête d'obtention et les listes de postes aptes à servir (LPS) et de postes potentiels (LPP), sont envoyées à un poste serveur central dans le cas où le document n'a pas été reçu suite à l'envoi séquentiel de la requête d'obtention. 41. Dispositif selon la revendication 38, caractérisé en ce que l'ordre prédéterminé de l'envoi est défini selon un critère de bande passante et/ou de temps de présence du poste dans le réseau de communication. 42. Dispositif selon la revendication 38, caractérisé en ce qu'il comporte des moyens de mise à jour de la table locale des index (TLI) suite à la réception en réponse à la requête d'obtention d'une nouvelle liste de postes serveur et d'une nouvelle liste de postes potentiels. 43. Dispositif selon la revendication 42, caractérisé en ce que les nouvelles listes sont prises en compte pour l'envoi séquentielle de la requête d'obtention. 44. Dispositif selon l'une quelconque des revendications 38 à 43, caractérisé en ce qu'il comporte des moyens d'envoi à destination des postes des listes de postes aptes (LPS) et de postes potentiels (LPP), d'un message de confirmation confirmant l'aptitude à servir le document numérique, suite à la réception d'une réponse à la requête d'obtention dudit document numérique. 45. Support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en oeuvre d'un procédé de partage selon l'une quelconque des revendications 1 à 22, lorsque ce programme est chargé et exécuté par un système informatique. 46. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de partage selon l'une quelconque des revendications 1 à 22, lorsque ce programme est chargé et exécuté par un système informatique.