Brevet FR2886494A1 — publié le 20061201

PROCEDE ET DISPOSITIF D'ECHANGE DE DONNEES ENTRE DES STATIONS MOBILES DANS UN RESEAU PAIR A PAIR La présente invention se rapporte à un procédé et à un dispositif 5 d'échange de données entre des stations mobiles dans un réseau pair à pair (en anglais "peer-to-peer' ou P2P). L'invention appartient au domaine du partage de données numériques multimédia et de l'accès à de telles données dans un réseau de communication distribué. Elle s'applique à tout document numérique monoou 10 multi-résolutions. Dans toute la suite, le terme "version" d'une donnée désigne la donnée à une résolution particulière. La donnée originale a la résolution la plus élevée et la même donnée à une résolution plus faible est appelée indifféremment "vignette" ou "imagette" (en anglais "thumbnaif'). Dans un système d'échange de fichiers pair à pair, chaque pair peut être à la fois client et serveur. Cela signifie que des données reçues par un pair jouant le rôle de client peuvent être servies à d'autres utilisateurs par ce même pair jouant le rôle de serveur. Des données auxquelles accèdent de nombreuses personnes peuvent donc être répliquées sur plusieurs machines et être servies par plusieurs serveurs. Une particularité importante des systèmes pair à pair est que leur topologie est généralement très instable. En effet, les postes clients (et par conséquent les serveurs) peuvent s'y connecter et s'y déconnecter à tout moment. Dans un tel environnement, l'accès aux contenus dans le réseau de communication représente un défi de taille. Les postes d'un système P2P sont en général des ordinateurs reliés en réseau par l'intermédiaire de l'Internet avec des moyens divers (PSTN, ADSL, etc.). Un système pair à pair dit hybride présente la particularité de comprendre un serveur permanent, appelé serveur central, qui peut servir à l'enregistrement des utilisateurs et à la gestion de la connexion des machines clientes de ces utilisateurs. Dans le but d'accroître la disponibilité des données numériques sur le réseau pair à pair et ainsi favoriser la qualité de service de la diffusion, le serveur central peut aussi stocker temporairement des versions limitées de données numériques personnelles. Dans le cadre de l'invention, on se place plus précisément dans le contexte d'un système de communication échangeant des données numériques 5 au moyen de conteneurs numériques de ces données. La présente invention sera décrite ici à titre d'exemple nullement limitatif dans une application où les données numériques, qu'il s'agisse de photographies, d'images ou de vidéos, peuvent être représentées en format de stockage hiérarchique de multiples représentations, en termes de résolution et de taille mémoire. Un conteneur numérique de telles données est par exemple une collection de photos numériques, c'est-à-dire un conteneur de références vers ces images dont diverses sous-parties ou représentations peuvent se retrouver sur diverses machines du réseau. De plus en plus couramment, on voit apparaître des postes clients dits "légers", tels que des appareils photo numériques ou des assistants personnels (PDA) disposant d'une connectivité vers l'Internet (par exemple, une connexion sans fil de type WiFi) : ceux-ci sont aptes à émettre des données numériques à partager sur le réseau P2P mais, au vu de leur capacités limitées, ils ne peuvent pas être considérés comme des serveurs de ces données. En effet, un utilisateur d'un appareil photo numérique désirant partager avec ses amis les photographies qu'il vient de prendre, sera confronté à des problèmes de temps et de coût de communication importants. Des solutions vont consister à n'émettre immédiatement qu'une version limitée de la donnée à partager, par exemple, une vignette d'une photographie, et à envoyer en différé la version originale par d'autres moyens: par exemple, cette même personne revient chez elle et synchronise l'appareil photo avec son ordinateur, qui est alors apte à envoyer la version d'origine de l'image sur le réseau P2P. Dans ce cas, les destinataires auront en premier lieu reçu un aperçu de la photographie, puis, dans un second temps, la version originale. Dans le cadre d'un réseau P2P hybride, si un ou plusieurs utilisateurs recherchent sur le réseau des données originales, à la suite de la réception d'une vignette, alors que ces données originales ne sont pas encore disponibles, cela entraîne des conséquences graves pour le réseau, telles qu'une surcharge inutile du réseau P2P et un engorgement des requêtes de recherche sur le serveur central. On connaît par le document EP-A-1 133 104 une méthode de transfert d'images d'un appareil photo vers un destinataire à travers un système serveur. Lors de la prise de photos, pour permettre une distribution moins coûteuse des images vers le serveur, le dispositif mobile engendre une version basse résolution de la photographie originale. La seconde étape consiste à envoyer les versions basse résolution des photographies vers le serveur en passant par la connexion radio. Ensuite, le serveur se chargera de l'acheminement vers les destinataires du réseau. Après avoir visionné la vignette, chaque destinataire peut éventuellement indiquer au serveur son désir d'obtenir l'original haute résolution dans l'immédiat, ou plus tard. Enfin, à la suite de cette information, un transfert de la photographie originale est effectué, soit directement, soit indirectement, en passant par le serveur, vers les destinataires ayant demandé la photographie originale. Cette méthode de transfert d'images présente plusieurs inconvénients. Tout d'abord, il n'est nullement tenu compte du cas où le dispositif mobile n'est plus présent lors de la réponse des destinataires pour obtenir l'image haute résolution. En outre, il n'est nullement tenu compte du cas du re-partage d'une même image. Par ailleurs, il n'y a pas de notion de changement d'état de la donnée partagée. Par ailleurs, on connaît par le document US-A-2003/0021591 une 30 méthode pour échanger des photographies numériques entre des personnes présentes en un même lieu. Après la prise des photographies, un signal de synchronisation est transmis afin que tous les appareils photo connaissent la base de données où résideront les photos prises. L'appareil photo ayant pris la photo se connecte à cette base de données, et y transfère ses images. Tous les autres possesseurs d'appareil photo peuvent ensuite télécharger les images. La base de données peut être réalisée par un appareil photo connecté (mémoire de l'appareil), par un ordinateur (disque dur contenant les photos), ou par un serveur Web accessible. Il n'y a pas de signalisation de la présence effective de données dans le système. Cette méthode ne permet donc pas d'empêcher qu'un utilisateur effectue sur le réseau une recherche de versions des données qui ne sont pas encore introduites dans le réseau. L'invention a pour but de remédier aux inconvénients mentionnés ci-dessus, d'une part, en permettant le partage de données numériques partielles en provenance d'un client léger dans un réseau P2P, dans le cas où une personne souhaite informer rapidement ses amis destinataires du partage de ses nouvelles images et, d'autre part, en évitant les recherches de versions des données numériques non encore présentes dans le réseau: il est légitime que le destinataire d'un partage souhaite recevoir de meilleures résolutions des images/documents, mais cela ne doit pas nuire aux performances et à la qualité de service du réseau en général et du serveur central en particulier. Dans ce but, la présente invention propose un procédé de partage de données numériques dans un réseau de communication pair à pair, suivant lequel on transmet, à des postes destinataires de ces données, dans un premier temps, une version partielle des données partagées, ce procédé étant remarquable en ce qu'il comporte des étapes suivant lesquelles: - on crée une collection de données, dans laquelle on associe un identifiant à chaque donnée et on attribue à chaque identifiant de donnée un label indiquant si la version complète de la donnée est disponible sur le réseau; - on notifie à au moins un poste destinataire l'existence de cette collection; et 2886494 5 à réception d'informations de disponibilité sur le réseau des versions complètes des données de la collection: - on met à jour la collection; et - on notifie au(x) poste(s) destinataire(s) la mise à jour de la 5 collection partagée. La présente invention permet ainsi d'obtenir une réduction significative du coût du service d'un serveur central qui mettrait en oeuvre ces étapes. En effet, d'une part, aucune recherche n'est effectuée pour des données qui ne sont pas encore introduites dans le réseau et, d'autre part, l'impact d'une double notification est mineur comparé à la charge économisée sur le serveur en termes de temps de traitement et de bande passante. En outre, la présente invention se traduit par une grande simplicité pour les utilisateurs: il n'y a pas d'action spécifique pour le pair qui partage des données; quant au receveur de la collection, il est informé de la raison pour laquelle aucune recherche ne sera faite sur la donnée demandée (à savoir, le fait que cette donnée n'est pas encore présente dans le réseau). De plus, la présente invention permet de réduire l'attente d'un destinataire d'une collection partagée, en l'empêchant de faire des recherches pour des contenus absents du réseau. La présente invention permet aussi d'éviter de mettre en oeuvre de lourdes méthodes de propagation d'information sur le réseau. Par ailleurs, la solution proposée par la présente invention est compatible avec les protocoles de sécurité en vigueur dans le réseau. En outre, les transferts importants de données sont toujours effectués 25 sur les canaux les moins coûteux. Dans un mode particulier de réalisation, la collection de données est constituée: - d'un en-tête, comportant un titre, un identifiant de collection et un identifiant de l'auteur de la collection, et - d'un corps, comportant une pluralité d'identifiants des données numériques de la collection, et une pluralité de labels respectivement associés aux identifiants des données, chaque label indiquant si la version complète de la donnée est disponible sur le réseau. La présence des labels dans le corps de la collection permet de conserver un moyen unique de transfert des informations utiles sur les contenus média, car cela évite d'utiliser un fichier alternatif dédié à un contenu média. Selon une caractéristique particulière, l'en-tête de la collection de données comporte en outre une signature. La signature permet de vérifier que la collection a bien été créée par l'auteur désigné par l'identifiant contenu dans l'en-tête de la collection et que la collection a été validée par le serveur d'authentification du réseau pair à pair. Un serveur central peut par exemple servir de serveur d'authentification conformément au protocole de sécurité du réseau pair à pair, car ce serveur gère les comptes des utilisateurs. La signature est par exemple fabriquée sur le serveur central avec la propre clé de chiffrement privée du serveur central. Pour valider une signature, un client peut, soit disposer de la clé publique correspondant à la clé privée qui a servi à signer la collection, auquel cas il peut décrypter la signature et compare la valeur obtenue avec son propre calcul de signature de la collection, soit faire appel au serveur central pour valider la signature. Selon une caractéristique particulière, le corps de la collection de données comporte en outre une pluralité d'identifiants d'utilisateurs autorisés à accéder à la collection. Dans un réseau pair à pair sécurisé, le créateur de la collection crée ainsi une limitation d'accès aux contenus de la collection, en n'autorisant que les personnes dont l'identifiant utilisateur est écrit dans la liste des identifiants d'utilisateurs de la collection. En variante, dans un réseau pair à pair non sécurisé, ou si la collection ne comporte pas de signature, cette liste d'identifiants d'utilisateurs est considérée comme étant une liste de diffusion pour les données média de la collection. 2886494 7 Dans un mode particulier de réalisation, chaque label est un drapeau dont la présence indique que la version complète de la donnée correspondante n'est pas disponible sur le réseau et dont l'absence indique que la version complète de la donnée est disponible sur le réseau. Le drapeau indique un état transitoire de la collection, dans lequel les versions haute résolution des données ne sont pas encore présentes sur le réseau. Ensuite, il n'y a plus de raison de conserver ce drapeau, ce qui permet d'alléger à la fois la taille mémoire utilisée par la collection et le traitement effectué par les pairs lors de l'analyse syntaxique (en anglais "parsing") de la collection. Dans un autre mode particulier de réalisation, chaque label est un booléen dont la valeur indique la présence ou l'absence de la donnée correspondante sur le réseau. Dans un mode particulier de réalisation, l'étape de mise à jour de la collection consiste à supprimer les labels correspondant aux données dont la version complète est disponible sur le réseau. Cela permet d'alléger à la fois la taille mémoire utilisée par la collection et le traitement utilisé par les pairs lors de l'analyse syntaxique de la collection. Dans une application privilégiée de l'invention, les données représentent des images numériques fixes et la version partielle d'une donnée est une version d'une image ayant une résolution inférieure à celle de l'image d'origine. Dans une autre application privilégiée de l'invention, les données représentent une vidéo numérique et la version partielle d'une donnée est la première image de la vidéo à une résolution inférieure à celle de la vidéo d'origine. Dans un mode particulier de réalisation, les étapes du procédé sont mises en oeuvre par un serveur central. Ce mode de réalisation est avantageux car le serveur central, continuellement connecté, est disponible pour tous les clients du réseau pair à pair. Il dispose également de toutes les informations nécessaires à la création d'une collection de documents numériques (gestion des comptes utilisateurs, serveur d'authentification, stockage temporaire de certaines versions des données partagées). Lorsqu'il est connecté sur l'Internet, par exemple par l'intermédiaire d'une borne relais sans fil, un dispositif mobile compatible peut communiquer avec le serveur central à tout moment. Dans un mode particulier de réalisation, on crée la collection de données à réception d'une requête de partage de données numériques en provenance d'une station mobile. La collection ainsi créée capitalise les informations reçues de la station mobile, qui sont alors transmises dans un format exploitable par les systèmes pairs du réseau. La collection conserve aussi si besoin l'information de la présence partielle sur le réseau des données partagées en provenance d'une station mobile. Dans ce mode de réalisation, la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après connexion de la station mobile précitée avec un poste pair du réseau et sur synchronisation de la collection entre cette station mobile et ce poste pair. Ainsi, la station mobile utilise une connexion locale, rapide et peu ou pas onéreuse, pour transmettre les versions haute résolution des données numériques partagées telles que des images. Le poste pair informe alors le réseau pair à pair de la disponibilité de ces versions dans sa zone de stockage dédiée au service pair à pair. Dans un autre mode particulier de réalisation, on crée la collection de données à réception d'une requête de partage de données numériques en 25 provenance d'un premier poste pair du réseau. Le premier poste pair crée la collection et l'envoie au serveur central. Si ce premier poste pair est uniquement utilisé dans le but de notifier la création d'une collection, et n'est pas destiné à servir de relais pour servir les documents numériques partagés, la collection peut être détruite localement sur ce poste pair après envoi au serveur. L'intérêt consiste à informer le plus rapidement possible les destinataires d'une collection partagée, même si toutes les versions des documents ne sont pas encore récupérables. Dans cet autre mode de réalisation, la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après mise à disposition de versions complètes des données par un deuxième poste pair du réseau. Dans le cas où le deuxième poste pair possède des capacités de connexion au réseau plus performantes que le premier poste pair, l'invention permet d'en tirer profit. Les versions haute résolution sont mises à disposition sur le réseau pair à pair à partir de ce deuxième poste. En variante, la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après mise à disposition de versions complètes des données par le premier poste pair après un temps prédéterminé. Ainsi, lors du début du partage des données, l'utilisateur du poste pair peut privilégier la bande passante pour d'autres services que le réseau pair à pair. Plus tard, lorsqu'il le souhaitera, le partage de la collection pourra être finalisé - entre-temps, les destinataires auront disposé d'une prévisualisation de cette collection encore partielle. Dans un mode particulier de réalisation, les étapes de création de la collection et de notification de l'existence de la collection sont mises en oeuvre par une station mobile, les étapes de mise à jour de la collection et de notification de mise à jour de la collection étant effectuées par une station pair du réseau ou par un serveur central. Des dispositifs mobiles possèdent des moyens pour créer des collections de données mais ont des capacités de connexion peu performantes et/ou coûteuses. On utilise leurs capacités CPU afin de décharger le serveur central. Dans ce mode de réalisation, la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après connexion de la station mobile précitée avec un poste pair du réseau et sur synchronisation de la collection entre cette station mobile et ce poste pair. Dans ce mode de réalisation, on crée la collection de données à réception d'une requête de partage de données numériques en provenance d'une seconde station mobile. Deux stations mobiles ont échangé entre elles des données numériques; si la première station mobile a des capacités de traitement suffisantes pour créer une collection temporaire, elle le fait. Sinon, la création de la collection s'effectue sur un poste pair du réseau après connexion de la première station mobile avec ce poste pair et sur synchronisation entre cette station mobile et ce poste pair. Dans ce cas, la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après connexion de la seconde station mobile précitée avec un poste pair du réseau et sur synchronisation de la collection entre cette station mobile et ce poste pair. Dans un mode particulier de réalisation, les étapes de création de la collection et de notification de l'existence de la collection sont mises en oeuvre par une station pair du réseau, les étapes de mise à jour de la collection et de notification de mise à jour étant effectuées par une autre station pair du réseau. Dans un mode particulier de réalisation, l'ensemble des étapes du procédé est mis en oeuvre par une station pair du réseau. Dans le même but que celui indiqué plus haut, la présente invention propose également un procédé de partage de données numériques dans un réseau de communication pair à pair, suivant lequel on transmet, à des postes destinataires de ces données, dans un premier temps, une version partielle des données partagées, ce procédé étant remarquable en ce qu'il comporte des étapes suivant lesquelles, au niveau d'un poste destinataire: à réception d'une notification indiquant l'existence d'une collection de données comportant un identifiant associé à chaque donnée, un label ayant été attribué à chaque identifiant de donnée pour indiquer si la version complète de la donnée est disponible sur le réseau, - on analyse les labels associés aux identifiants de données de la collection; - en cas d'existence de labels indiquant que la version complète d'une donnée n'est pas disponible sur le réseau, on restreint les droits de traitement associés à cette donnée; et - à réception d'une notification de mise à jour de la collection, on supprime la restriction des droits de traitement. Selon une caractéristique particulière, le procédé comporte en outre une étape d'affichage des restrictions des droits de traitement. Ainsi, l'utilisateur sait, en consultant l'interface graphique, que les commandes sont limitées, ce qui lui évite d'essayer en vain différentes 10 commandes. La restriction des droits de traitement peut être une interdiction de demande de version complète de la donnée et/ou une interdiction d'impression de la donnée si la donnée est une image et/ou une interdiction d'un nouveau partage de cette donnée. Toujours dans le même but, la présente invention propose en outre un dispositif de partage de données numériques dans un réseau de communication pair à pair, dans lequel des postes destinataires de ces données sont adaptés à recevoir, dans un premier temps, une version partielle des données partagées, ce dispositif étant remarquable en ce qu'il comporte: - une unité de création d'une collection de données, dans laquelle un identifiant est associé à chaque donnée et un label est attribué à chaque identifiant de donnée, ce label indiquant si la version complète de la donnée est disponible sur le réseau; - une première unité de notification, pour notifier à au moins un poste destinataire l'existence de la collection; - une unité pour mettre à jour la collection; et - une seconde unité de notification, pour notifier au(x) poste(s) destinataire(s) la mise à jour de la collection partagée. Toujours dans le même but, la présente invention propose aussi un dispositif de partage de données numériques dans un réseau de communication pair à pair, dans lequel des postes destinataires de ces données sont adaptés à recevoir, dans un premier temps, une version partielle des données partagées, ce dispositif étant remarquable en ce qu'il comporte, au niveau d'un poste destinataire: - une unité d'analyse, pour analyser, à réception d'une notification indiquant l'existence d'une collection de données comportant un identifiant associé à chaque donnée, un label ayant été attribué à chaque identifiant de donnée pour indiquer si la version complète de la donnée est disponible sur le réseau, les labels associés aux identifiants de données de la collection; - une unité de restriction, pour restreindre les droits de traitement associés à la donnée précitée en cas d'existence de labels indiquant que la version complète d'une donnée n'est pas disponible sur le réseau; et - une unité de suppression de restriction, pour supprimer la restriction des droits de traitement à réception d'une notification de mise à jour de la collection. Toujours dans le même but, la présente invention propose 15 également un serveur de données dans un réseau de communication pair à pair, comportant: - une unité de stockage de données; - un serveur Web; -une interface de visualisation, couplée au serveur Web, et - une base de données, ce serveur étant remarquable en ce qu'il est adapté à exécuter un logiciel qui met en oeuvre un procédé tel que ci-dessus. La présente invention vise aussi un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, permettant la mise en oeuvre d'un procédé tel que ci-dessus. La présente invention vise aussi un moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé tel que cidessus. La présente invention vise aussi un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, comportant des séquences d'instructions pour mettre en oeuvre un procédé tel que ci- dessus, lorsque ce programme est chargé et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du dispositif, du serveur de données, des moyens de stockage et du produit programme d'ordinateur étant similaires à ceux du procédé, ils ne sont pas répétés ici. D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemples non limitatifs. La description se réfère aux dessins qui l'accompagnent, dans lesquels: - la figure 1 représente de façon schématique un réseau pair à pair ou P2P adapté à mettre en oeuvre la présente invention, dans un premier mode particulier de réalisation; la figure 2 représente de façon schématique un dispositif adapté à mettre en oeuvre la présente invention, dans un mode particulier de réalisation; - la figure 3 illustre une collection au sens de la présente invention, dans un mode particulier de réalisation; - la figure 4 illustre un mode particulier de réalisation d'un scénario de partage d'une collection à partir d'un appareil photo d'un réseau pair à pair; - la figure 5 est un organigramme illustrant la succession d'étapes effectuées conformément à la présente invention à réception d'une commande de partage à partir d'un client léger, dans un mode particulier de réalisation; - la figure 6 est un organigramme illustrant la succession d'étapes effectuées conformément à la présente invention à réception d'une commande de partage à partir d'un poste pair dans un mode particulier de réalisation; - la figure 7 est un organigramme illustrant un mode particulier de réalisation d'un scénario de visualisation d'une collection sur un poste destinataire; - la figure 8 représente de façon schématique un réseau pair à pair adapté à mettre en oeuvre la présente invention, dans un second mode particulier de réalisation; et - la figure 9 représente de façon schématique un réseau pair à pair adapté à mettre en oeuvre la présente invention, dans d'autres modes particuliers de réalisation. La description détaillée qui suit se fonde sur un exemple de système optimal où le serveur central ne conserve que des versions basse résolution, à savoir, au moins les vignettes, des données numériques. Parmi les divers types de fichiers numériques auxquels peut s'appliquer la présente invention, on trouve: - des images numériques fixes dont la représentation basse résolution est une vignette ou imagette et dont la donnée originale correspond à l'image originale c'est à dire à pleine résolution; - de la vidéo, où la donnée originale correspond à la séquence d'images originales et la vignette correspond, par exemple, à la premièreimage de la vidéo à une résolution inférieure à la résolution de la vidéo originale. Le début d'un flux vidéo peut aussi par exemple représenter une description vignette de la vidéo complète; - des fichiers informatiques d'application bureautique (bien souvent, les premiers octets de ces fichiers permettent de connaître le type d'application logicielle requise pour les lire, et ainsi l'utilisateur destinataire du partage peut choisir ceux des fichiers qu'il est apte à visualiser). Dans un mode préféré de réalisation, les données multi-résolutions partagées par l'invention sont des images ou des photographies numériques. Une vue d'ensemble d'un réseau pair à pair adapté à mettre en oeuvre la présente invention est illustrée sur figure 1. Un réseau 190 tel que l'Internet permet des communications suivant une architecture du type client-serveur, où chaque client 100 ou 120 accède périodiquement à un serveur central 110. Des connexions pair à pair parmi les appareils informatiques 100 des utilisateurs sont également effectuées pour échanger des données à partager et ce, indépendamment du serveur central 110. Les utilisateurs peuvent se connecter sur le réseau de diverses façons: par exemple, par l'intermédiaire de modems DSL, 56k, ou câble, mais aussi depuis des postes de téléphonie 2886494 15 mobile (par exemple de type GSM) ou encore à partir de postes nomades disposant d'une connexion sans fil (par exemple de type WiFi). Le réseau 190 peut tout aussi bien être un réseau local (LAN) privé. Le serveur central 110 peut être composé de plusieurs serveurs couplés entre eux et accessibles à partir d'une seule adresse réseau. Les terminaux 100 peuvent communiquer directement ou par l'intermédiaire du serveur central 110. Chaque serveur 110 peut par exemple être un dispositif tel que décrit plus loin en liaison avec la figure 2, et comporte en particulier un dispositif de stockage de données volatiles 160 (on parle de mémoire cache, qui peut contenir des données à durée de vie longue telles que des images, mais aussi des données plus volatiles telles que des listes d'adresses), et une interface homme-machine qui permet l'interaction avec un administrateur de ce serveur. Chaque terminal 100 peut également être un dispositif tel que décrit à la figure 2. Les terminaux 100 peuvent être connectés à différents périphériques tels que, par exemple, une caméra numérique, ou un scanner, ou tout moyen d'acquisition ou de stockage d'image, fournissant des données multimédia. Les terminaux 120 sont plus particulièrement des clients légers, tels qu'un assistant numérique ou un appareil photo ou un téléphone portable, disposant d'une connexion vers le réseau 190. S'ils ne possèdent pas en interne des capacités et moyens d'acquisition ou de stockage d'image, ces appareils 120 peuvent être connectés à différents périphériques tels que, par exemple, une caméra numérique. Généralement, ces terminaux 120 se connectent sur le réseau 190 par le biais d'un réseau de téléphonie mobile (par exemple de type GSM), ou par des bornes relais d'un réseau sans fil local du type WiFi ou Bluetooth. Le serveur central 110 peut exécuter une application, illustrée sur la figure 1 par le logiciel 130, qui englobe les algorithmes de l'invention. Le serveur central 110 comprend une interface de visualisation 140, qui peut correspondre à un navigateur Internet. Cette interface est couplée à un serveur Web 150. Le serveur Web 150 est un serveur classique (tel que Apache ou Microsoft IIS) exécutant des modules logiciels 130 propres à l'invention. En variante, le logiciel 130 et le serveur 150 peuvent constituer une seule et même entité. Comme indiqué plus haut, le serveur central 110 est aussi composé d'un dispositif de stockage tel qu'un disque dur 160, sur lequel seront stockées les données à conserver temporairement (en particulier les imagettes relatives aux photos numériques à partager) et d'une base de données 180 contenant des identifiants uniques, propres à différentes entités du système global (en particulier, les identifiants des utilisateurs et les identifiants des images). Un dispositif mettant en oeuvre la présente invention est illustré sur la figure 2. Le serveur central 110 ainsi que les terminaux 100, par exemple, peuvent répondre à la description suivante. Ce dispositif peut être par exemple un micro-ordinateur 200 ou une station de travail. Ce dispositif est connecté à différents périphériques tels que, par exemple, tout moyen de stockage d'image relié à une carte graphique et fournissant au dispositif 200 des données multimédia. Le dispositif 200 comporte un bus de communication 202 auquel sont reliés: - une unité centrale de traitement (microprocesseur) 203, - une mémoire morte 204, pouvant contenir des programmes "Prog" supportant l'invention, - une mémoire vive 206 (mémoire cache), comportant des registres adaptés à enregistrer des variables et des paramètres créés et modifiés au cours de l'exécution des programmes précités, - un écran 208 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 210 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 211 ou un crayon optique, - une interface de communication 218 reliée à un réseau de communication distribué 220, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données. Le dispositif 200 peut également comporter, en option: - un disque dur 212 pouvant contenir les programmes "Prog" précités, - un lecteur de disquettes 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter conformément à la présente invention. Le bus de communication 202 permet la communication et l'interopérabilité entre les différents éléments inclus dans le micro-ordinateur 200 ou reliés à lui. La représentation du bus n'est pas limitative et notamment, l'unité centrale 203 est susceptible de communiquer des instructions à tout élément du micro-ordinateur 200 directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 200. Le code exécutable de chaque programme permettant au dispositif 200 de mettre en oeuvre les processus selon l'invention peut être stocké, par exemple, dans le disque dur 212 ou en mémoire morte 204. En variante, la disquette 216 peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 200, sera stocké dans le disque dur 212. Dans une autre variante, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 220, via l'interface 218, 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 façon générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif 200, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé conforme à la présente invention. De façon plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 200 avant d'être exécutés. L'unité centrale 203 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes conformes à l'invention, instructions qui sont stockées dans le disque dur 212 ou dans la mémoire morte 2886494 18 204 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 212 ou la mémoire morte 204, sont transférés dans la mémoire vive (RAM) 206, qui contient alors le code exécutable du ou des programmes conformes à l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Il convient de noter que l'appareil de communication comportant un dispositif 200 conforme à la présente 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). La figure 3 illustre une collection 300 au sens de la présente invention, c'est-à-dire un ensemble de références se rapportant à des contenus de médias (image, vidéo, son) avec des informations associées, appelées communément "méta-données". Ces méta-données sont par exemple des renseignements relatifs à un contenu média tel qu'un commentaire, la résolution d'origine d'une image, le taux de compression d'une vidéo, etc. Un contenu média peut être une méta-donnée d'un autre contenu média. Il peut aussi y avoir des méta-données pour la collection elle-même, telles que le titre de la collection, son auteur, une date, etc. Par extension, une collection peut contenir des collections, appelées des souscollections. Dans la description qui suit, on se place dans le cas du partage d'une collection d'images numériques par un système d'archivage d'un terminal 100 ou 120 dans un réseau de type pair à pair. Dans ce contexte, on appelle "imagette" (en anglais "thumbnait") la version basse résolution d'une image numérique et "image" la version haute résolution de cette image numérique, étant entendu que la présente invention ne se limite pas à seulement deux résolutions. Ainsi, dans la suite, on appelle "image multi-résolutions" aussi bien des images numériques de format multi-résolutions (telles que des images au format JPEG2000) que des images numériques mono-résolution (par exemple le format JPEG). Dans ce second cas, la notion de multi-résolutions est supportée par la construction de fichiers indépendants correspondant à des sous-résolutions différentes obtenues à partir d'un même fichier image haute résolution. Comme le montre la figure 3, chaque objet correspondant à une image numérique est identifié par un identifiant 303, créé sur la machine de l'utilisateur. Cet identifiant est attribué par l'application cliente même si celle-ci n'est pas connectée sur le réseau. Une solution consiste à produire localement des nombres aléatoires. En option, ces identifiants peuvent être uniques afin de faciliter les recherches sur le réseau. Des outils bien connus de l'homme du métier permettent d'engendrer des identifiants avec une infime probabilité de duplication. Des images seront de même définies par un identifiant 303 par l'application du client dès qu'une nouvelle image est ajoutée à une collection. Si l'image est copiée à partir d'une collection existante, elle conservera l'identifiant original. Cependant, une imagette a le même identifiant qu'une image. Afin de déterminer de manière précise un objet (image ou imagette), l'identifiant 303 doit être associé à un "typage" de donnée: la plupart du temps, ce typage est implicite selon les requêtes envoyées sur le réseau (en cas de téléchargement, l'image est demandée alors que I'imagette est utile pour une visualisation simple). Chaque utilisateur a aussi un identifiant unique 304 fourni par le serveur central pendant le procédé d'enregistrement de l'utilisateur. Cette propriété est utile pour réduire au minimum le risque d'enregistrements multiples pour un même utilisateur. Dans le mode de réalisation préféré, en achetant le logiciel client, l'acheteur enregistre son logiciel et établit avec le serveur central 110 un compte qui identifie cet utilisateur. Ce compte identifié par l'identifiant 304 sert à la fois pour une connexion du client par le logiciel standard ou par un navigateur Internet. 2886494 20 Dans le mode de réalisation préféré décrit ici, une collection 300 comporte, d'une part, un en-tête 300H et, d'autre part, un corps 300B. L'en-tête 300H comporte un titre 301, un identifiant 302 de la collection et l'identifiant 304 de l'auteur de la collection. Une signature 306 permettant de vérifier que la collection a bien été créée par l'auteur et a été validée par le serveur central 110 peut être ajoutée. La signature 306 est fabriquée sur le serveur central par une fonction de hachage connue en soi (par exemple, MD5) appliquée sur la collection, puis cette signature est signée avec la propre clé de chiffrement privée du serveur 110. Pour valider une signature, un client peut, soit disposer de la clé publique correspondant à la clé qui a servi à signer la collection (dans ce cas, il peut décrypter la signature et comparer la valeur obtenue avec son propre calcul de la fonction de hachage appliquée à la collection), soit faire appel au serveur central pour valider la signature. La création de la signature est une opération connue en soi. D'autres méta-données peuvent être ajoutées, telles que la date de création, etc. Le corps 300B comporte une liste d'identifiants 303 des objets numériques de cette collection. La plupart des systèmes d'échange de fichiers pair à pair sont destinés à l'échange de données publiques: tout le monde peut accéder à une donnée partagée. Dans le contexte d'échange de données personnelles (par exemple d'images ou de vidéos qu'une personne désire partager avec ses amis ou sa famille), il est nécessaire d'avoir un système pour restreindre l'accès aux données. Dans ce cas, la collection contient aussi une liste de distribution, c'est-à-dire une liste d'utilisateurs autorisés à visualiser la collection, identifiés par des identifiants 304. A chaque identifiant 303 du corps de la collection 300B est associé un statut 305 indiquant un état spécifique à la donnée identifiée par 303, correspondant à la présence/absence de version haute résolution de l'image sur le réseau P2P. Cet état peut être représenté indifféremment de plusieurs façons: - le statut 305 est un drapeau: la présence de ce drapeau indique que la version haute résolution du document n'est pas disponible sur le réseau. Son absence n'indique aucune restriction lors de requêtes futures sur l'élément concerné car la version haute résolution est disponible quelque part dans le réseau. Par exemple, en langage XML, pour une image: - le statut 305 est une étiquette ou label attaché à un élément de la 10 collection: la valeur booléenne affectée à cette étiquette indique la présence ou non de la version haute résolution de l'élément visé. Par extension, l'absence de ce label est identique à une valeur fausse par défaut ("false"). Par exemple, pour une image: On notera que cette étiquette n'est pas limitée à deux valeurs, mais peut comporter de multiples valeurs entières représentant par exemple un degré de présence de différentes versions de documents disponibles: en effet, la présence partielle de données numériques sur le réseau est directement fonction des capacités des terminaux 120 partageant ces documents sur le réseau (par exemple, un appareil photo 120 performant disposant d'une connexion à haut débit serait capable d'introduire initialement sur le réseau plus de versions de résolution intermédiaire des documents partagés). Dans la suite, le terme "label" sera communément utilisé pour désigner le statut 305. De préférence, le label 305 ne sera pas mentionné dans la collection s'il n'y a pas de restriction pour l'accès à une version, quelle qu'elle soit, des documents. La création d'une collection par un utilisateur sur un poste 100 n'est pas le propos de l'invention. Il existe des procédés bien connus de l'homme du métier qui ont trait aux images et à leur association à des conteneurs d'images. Par exemple, l'utilisateur peut copier une image depuis l'interface graphique du système d'exploitation de son ordinateur et la déposer dans l'interface graphique 140 du logiciel mettant en oeuvre l'invention. L'utilisateur peut structurer ses images, collections et sous-collections de façon à finalement enregistrer chaque collection 300 créée sous forme d'une liste d'identifiants d'images, de sous-collections. Chaque collection peut éventuellement comprendre une ou plusieurs méta-données de faible taille mémoire, par exemple une imagette représentative de la totalité de la collection. Une collection peut aussi comprendre des informations (non représentées sur la figure 3) pour le rendu lors de l'affichage (aussi bien pour le logiciel P2P exécuté sur les postes pairs que pour un affichage sur le serveur Web 150 du serveur central 110), telles que: nombre d'images par page, image de fond, bordures des images, etc. Pour une collection créée par un poste pair 100, la présence du label 305 est optionnelle. Comme le poste 100 est un poste client/serveur, le procédé de l'invention lors de la création de la collection ne s'applique pas: si le label 305 est indiqué, sa valeur doit obligatoirement être mise à "false". Une représentation physique d'une collection peut par exemple consister en un codage en langage XML: Un utilisateur souhaitant partager une collection d'images à partir d'un terminal 120 peut être confronté à des capacités de calcul limitées de ce terminal pour créer cette collection 300. Ainsi, le serveur central 110 est utilisé comme support pour la création de la collection 300 pour le partage de données à partir de terminaux 120. Le serveur 110 utilisera le label 305 pour indiquer aux postes clients si les images originales circulent dans le réseau P2P, afin d'autoriser d'éventuelles opérations telles que des recherches. La figure 4 présente un mode particulier de réalisation d'un scénario normal de partage de documents numériques tels que des photographies à partir d'un appareil photographique 120 dans le réseau pair à pair, conformément à la présente invention. Un utilisateur A prend des photographies avec son appareil numérique 120 (étape 1), qui est un client léger. Ce terminal 120 peut contenir un logiciel dédié pour se connecter au serveur central 110 du réseau P2P, ou utilise un navigateur Internet pour se connecter à l'interface Web du serveur 110. Dans un mode préféré de réalisation de l'invention, le client léger 120 possède un logiciel embarqué lui permettant d'envoyer des messages au serveur 110: un message est par exemple formaté en langage de balisage XML tel que SOAP et est transporté par le protocole de communication HTTP dans une requête de type POST. Il est à noter que le client 120 est l'initiateur de toute requête sur le serveur 110, car le terminal 120 n'a pas les capacités suffisantes pour embarquer un serveur local, et ainsi le serveur 110 ne peut interroger directement l'appareil 120. Cependant, le terminal 120 possède toutes les capacités processeur pour créer au moins une version limitée, c'est-à-dire une imagette, de chaque image photographique saisie. Ainsi, lorsqu'il est connecté à l'Internet par les moyens décrits en liaison avec la figure 1, le terminal 120 est capable d'envoyer une requête de partage d'images vers le serveur 110 (étape 2). En variante, le terminal 120 peut lui-même créer la collection, de façon similaire au serveur, comme décrit plus loin en liaison avec la figure 5. Dans un mode de réalisation préféré, le terminal 120 attribue des identifiants uniques 303 aux images qui vont être partagées, ces identifiants étant compatibles avec le format des identifiants des données véhiculées dans le réseau P2P. En option, ces identifiants 303 peuvent être demandés au serveur 110 par une requête dédiée. Un nouvel identifiant 303 peut être créé en prenant par exemple un nombre aléatoire avec une taille suffisante pour avoir une très faible probabilité d'obtenir plusieurs fois le même identifiant. La requête de partage contient donc les identifiants 303 des images à partager, ainsi que quelques méta-données supplémentaires à incorporer dans la future collection: identifiant 304 du possesseur du terminal 120, liste des identifiants 304 des destinataires de ce partage préalablement sélectionnés par l'interface graphique du terminal 120. En option, les identifiants 304 des utilisateurs peuvent être remplacés par des adresses de messagerie électronique. Ces informations peuvent avoir été entrées par avance par l'utilisateur dans la mémoire du terminal 120, soit par saisie directe sur l'interface graphique du terminal, soit par l'intermédiaire d'un logiciel situé sur le poste 100 lors d'une précédente synchronisation avec le terminal 120. Dans un mode particulier de réalisation, si le terminal 120 ne possède pas d'interface graphique évoluée permettant la saisie de texte, le titre de la collection pourra être composé au choix de la date courante, du numéro de série ou de la marque du terminal, de l'identifiant 304 du possesseur, etc. Dans ce cas, ces informations sont ajoutées à la requête de partage envoyée au serveur 110. A la suite de la réception de la requête de partage, le serveur 110 indique dans sa réponse la liste des images qu'il désire recevoir: il s'agit au minimum des imagettes qui serviront lors de la notification de la nouvelle collection partagée aux destinataires. Les actions produites par le serveur 110 (et notamment la création de la collection Cl) sont décrites plus loin en liaison avec la figure 5. Dans le cas où le terminal 120 contiendrait des images déjà partiellement partagées (cas d'un précédent partage à partir de ce terminal) ou complètement partagées (cas d'un précédent partage à partir de ce terminal avec synchronisation effectuée avec le poste 100, ou images reçues du réseau P2P), le serveur 110 ne demanderait dans sa réponse que le téléchargement des versions des images (ici les imagettes) qui lui manquent. Une série de messages suit alors, afin d'envoyer sur le serveur central 110 les imagettes demandées. Ces messages sont par exemple des messages HTTP PUT. Chaque message comporte une référence à la collection Cl créée sur le serveur, l'identifiant 303 de I'imagette et l'imagette elle-même. A la fin du transfert des imagettes, le serveur positionne le label 305 pour chaque image de la collection Cl provenant du transfert précédent. Ensuite, le serveur 110 notifie une première fois aux destinataires le partage en cours (étape 3). La réalisation de cette notification ne fait pas l'objet de l'invention: il peut s'agir d'une notification interne au réseau P2P, mais aussi d'une notification avec des outils externes (tels que la messagerie électronique ou un système de messagerie instantanée). Dans les deux cas, la notification peut comprendre une vignette correspondant à l'imagette de la première image de cette collection, ou bien à une imagette représentant la première page de la collection. Il est possible de transmettre la collection Cl en pièce jointe au message de notification. Une alternative consiste pour le serveur central 110 à envoyer une simple notification aux destinataires indiquant que Cl est disponible chez lui. Dans le cas d'une notification interne au réseau P2P, à réception de ce message de notification, l'application P2P peut automatiquement dialoguer avec le serveur 110 afin de récupérer la collection Cl ainsi que les premières versions des images composant Cl. Dans le cas d'une notification externe, une intervention simple de l'utilisateur est nécessaire afin de visualiser la collection Cl: il peut par exemple cliquer sur un lien de type URL dans le message de notification, qui lui permet de démarrer l'application P2P ou un navigateur Web sur la première page de la collection Cl. Le contenu précis de cette première notification est décrit ultérieurement à l'étape 506 de la figure 5. Les personnes recevant la notification sont alors en mesure de visualiser en basse résolution la collection Cl d'images que vient de prendre leur ami A. Dans un deuxième temps, ils seront informés de la possibilité d'obtenir les originaux de ces documents partagés lors d'une seconde notification. Il est à noter que si la collection Cl contient des documents déjà complètement partagés sur le réseau, les versions haute résolution de ceux-ci peuvent bien sûr être obtenues à partir de Cl (dans ce cas, il n'y a pas de label 305 dans la collection). Dans une variante de réalisation, au cas où le poste mobile 120 a les moyens nécessaires pour le faire, il effectue à la fois la création de la collection, avec des labels associés aux identifiants des données, et la notification aux destinataires. En revenant chez lui, l'utilisateur A synchronise son appareil 15 photographique 120 avec son ordinateur personnel 100 possédant le logiciel de connexion au réseau P2P (étape 4). Cette action s'effectue en reliant le terminal 120 au port USB ou série du poste 100, ou par l'intermédiaire d'une liaison sans fil, comme par le protocole WiFi ou Bluetooth, par exemple. Les étapes suivantes détaillent l'action de synchronisation locale: - le terminal 120 télécharge les originaux des images sur le PC 100. Ces originaux sont automatiquement référencés dans le logiciel P2P par l'association avec les identifiants 303. Des méta-données (identifiants 302 des collections nouvelles telles que la collection Cl, identifiants 303 des images, carnet d'adresses des destinataires amis) informent le logiciel P2P des nouveautés. En option, les versions imagettes créées sur le terminal 120 sont aussi récupérées afin de limiter les calculs sur le poste 100. - récupération sur le réseau de la collection Cl référencée par 302. Si le poste 100 n'est pas connecté par l'Internet sur le réseau P2P, cette collection 30 peut aussi être recomposée localement sur le poste 100. Dans les deux cas, le poste 100 dispose maintenant d'une collection identique à Cl et de toutes les images nécessaires à un partage classique dans le réseau P2P. A l'étape 5, une synchronisation du poste 100 avec le serveur 110 pour la collection Cl est effectuée. Il peut s'agir d'un message particulier informant le serveur 110 qu'un système pair (le poste 100 de l'utilisateur A) dispose maintenant des versions originales des images de la collection Cl créées à partir d'un terminal léger. Dans un mode de réalisation préféré, ce message est véhiculé vers le serveur 110 comme un message de création/partage d'une nouvelle collection: l'intérêt est de limiter la complexité de l'interface de communication du serveur 110, celui-ci ayant la charge de vérifier si la collection à partager est réellement nouvelle et d'agir en conséquence (voir ci-après la description de la figure 6). En réponse, le serveur 110 indique la liste des images manquantes pour compléter la collection, que le système pair 100 doit lui fournir. Quand le poste 100 a envoyé toutes les images manquantes au serveur 110,le serveur 110 supprime les labels 305 correspondant aux images reçues et peut valider la collection Cl en incorporant une signature 306 dans le fichier collection. Une seconde notification est envoyée aux destinataires pour la collection mise à jour (étape 6). Cette notification utilise de préférence le même canal de transmission que la première notification, mais le contenu du message est légèrement différent: par exemple, le titre du message indique qu'il s'agit d'une mise à jour d'une collection partagée mais le corps du message peut être identique (le lien de type URL vers le fichier collection est le même). Une description du contenu de la notification est précisée à l'étape 607 de la figure 6. Dans un mode de réalisation préféré, la seconde notification peut être émise par le poste pair 100, afin de décharger le serveur central 110. Les destinataires peuvent alors obtenir la collection Cl finale et profiter pleinement des services P2P pour les images partagées à partir d'un appareil photographique. En effet, la nouvelle version de la collection ne comprend plus aucun label 305, ce qui indique que toutes les versions originales des documents référencés dans la collection sont introduites dans le réseau P2P. L'organigramme de la figure 5 illustre les étapes successives du logiciel 130 exécuté sur le serveur central 110 lorsqu'un système client léger 120 requiert un partage d'images, en envoyant un message contenant une requête de partage. Ce message est de préférence formaté en langage XML et transporté via le protocole SOAP sur HTTP. Comme le client léger 120 n'a pas les capacités pour créer une collection localement, le message contient les métadonnées nécessaires à la construction de la collection sur le serveur 110. A l'étape 500, le serveur 110 reçoit une liste d'identifiants d'images à partager ainsi que des méta-données précisant l'auteur du partage, les destinataires, le titre de la collection. A l'étape 501, une collection provisoire Cl est créée. Lors d'une première étape, les en-têtes de la collection sont créés: le titre, l'identifiant de l'auteur, ainsi que la date de création. Un nouvel identifiant de collection est créé. Ensuite, l'identifiant 303 de chaque image est ajouté à la nouvelle collection. De plus, l'identifiant 304 de chaque utilisateur est ajouté à la nouvelle collection. Si l'utilisateur de l'appareil 120 a saisi une adresse de messagerie électronique à la place d'un identifiant 304 pour préciser un destinataire du partage, le serveur central 110 interroge sa base de données 180 pour obtenir des informations sur ce destinataire. Si le destinataire est une personne enregistrée dans le système, le serveur central lui a attribué un identifiant 304 qui peut alors être inscrit dans la collection à la suite des autres destinataires de la collection. Si l'adresse de messagerie électronique n'est pas contenue dans la base de données 180, le champ 304 comprend l'adresse de messagerie électronique de ce destinataire. De préférence, cette adresse n'est pas inscrite en clair dans la collection: on calcule une signature par un algorithme de hachage connu en soi (par exemple MD5). Une autre possibilité consiste à créer un compte provisoire pour le nouveau destinataire de la collection, afin d'obtenir un identifiant 304 unique affecté à cette adresse de messagerie électronique. A l'étape 502, pour chaque identifiant d'image 303, les nouvelles images provenant de l'appareil 120 sont listées (liste L1). En analysant la liste des images reçues, le serveur central 110 est capable de connaître quelles sont les nouvelles images à partir de son cache de données 160. Si une imagette référencée dans la collection est présente dans le cache 160, il s'agit d'une image re-partagée par l'utilisateur de l'appareil 120. Il est à noter que le terminal 120 peut demander plusieurs partages à suivre concernant les mêmes images. Dans ce cas, les imagettes sont déjà présentes mais ces images ne doivent cependant pas être considérées comme complètement disponibles tant que la synchronisation avec le pair 100 n'a pas été effectuée. Une première solution consiste, pour le serveur 110, à conserver une liste des identifiants 303 des images en provenance d'appareils de type 120 dont le partage n'est pas terminé. Une seconde solution consiste à conserver la liste des collections non validées en provenance d'un terminal 120 particulier, et à vérifier que les identifiants 303 reçus à l'étape 500 ne font pas partie de ces collections. Une troisième solution consiste à mémoriser dans la zone de stockage 160 cette information sur l'aspect partiel du partage, qui sera indiquée à chaque test d'accès sur l'imagette. Ainsi, une solution consiste à utiliser un fichier marqueur associé à chaque image/imagette. De préférence, une autre solution consiste à déduire cette information de donnée partielle à partir de l'absence d'une version de résolution supérieure de l'image dans le dispositif de stockage 160. Pour toutes ces images repartagées provenant du poste 120, un 25 label 305 est positionné dans la collection Cl. Dans un mode particulier de réalisation, la durée de vie des imagettes dans le cache 160 est limitée: ainsi, si des imagettes référencées par un identifiant 303 dans la collection ne sont pas présentes dans le cache 160, le système ne peut pas en déduire que ces images sont nouvelles. Pour être en mesure de vérifier si des images sont nouvelles, le serveur 110 conserve la liste des identifiants d'images qu'il a reçus en provenance des clients. Cette liste d'identifiants 303 utilisés dans le réseau peut être enregistrée dans une table de la base de données 180, ou tout aussi bien dans une zone de la mémoire 160 du serveur, auquel cas on pourra prévoir l'architecture de cette zone de façon à optimiser les recherches des identifiants. Si les identifiants 303 ne sont pas trouvés dans cette liste, les images correspondantes sont considérées comme nouvelles et ajoutées à la liste L1. Au moins les versions vignettes sont nécessaires pour débuter le partage. Elles serviront pour proposer un minimum d'affichage aux destinataires de la collection. A l'étape suivante 503, la liste L1 est renvoyée au terminal 120 en réponse à la requête reçue à l'étape 500. Celui-ci est alors chargé de transmettre les imagettes demandées. Pour chaque imagette reçue, le label 305 de la collection Cl correspondant à l'image 303 est positionné (étape 507). Ce label 305 servira aux postes pairs pour limiter les actions effectuées sur les images concernées. Lorsque toutes les imagettes demandées sont reçues (test 504 positif), la collection est vérifiée et stockée dans la mémoire 160 du serveur 110 (étape 505). Elle est donc disponible pour les systèmes pairs 100 du réseau autorisés à la télécharger. Ensuite, une notification est émise vers les destinataires inscrits dans la collection (étape 506). Cette notification peut inclure le fichier collection, ou bien un lien de type URL précisant la localisation du fichier sur le serveur 110. De préférence, l'outil de notification (messagerie électronique, notification interne au réseau P2P, messagerie instantanée) supporte une interface graphique évoluée permettant l'affichage d'une imagette représentative de la collection, à savoir, soit l'imagette de la première image de la liste des images, soit une imagette représentant la première page de la collection. L'organigramme de la figure 6 illustre les étapes successives du logiciel 130 exécuté sur le serveur central 110 lorsqu'un système client-serveur pair 100 requiert un partage d'images. Le message reçu à l'étape 600 est un message classique du partage d'une collection créée par un poste pair 100: en effet, le pair 100 utilise le même protocole de partage pour une collection Cl en provenance d'un terminal 120, que pour une collection créée par son propre logiciel P2P local. Ce message est de préférence formaté en langage XML et transporté via le protocole SOAP sur HTTP. Indifféremment, la collection créée sur le 5 système pair 100 sera incluse dans le message SOAP ou en pièce jointe à ce message. Dans un autre mode particulier de réalisation, il est aussi possible que le message envoyé à partir du poste pair 100 soit réalisé par l'envoi du fichier collection dans un message HTTP de type PUT ou POST. En option, le message envoyé contient une information d'authentification du système pair 100, positionnée dans le corps SOAP ou dans l'entête http, afin que le serveur puisse vérifier que ce pair est autorisé à créer/modifier une/la collection. La spécificité réside ici dans le fait que ce message est utilisé afin de compléter un partage commencé par un client léger 120, et non pas pour partager une nouvelle collection créée par le pair 100 comme c'est le cas habituellement. L'intérêt consiste à ne pas multiplier les messages échangés entre les machines du réseau et à garder une compatibilité ascendante des interfaces de communication. II est à noter que les messages reçus aux étapes 500 (figure 5) et 600 (figure 6) sont de préférence distincts. Cependant, lorsque le message correspond à un message SOAP formaté en langage XML, cette restriction n'est nullement obligatoire: il est tout à fait possible que le client léger 120 utilise le même message en ne fournissant que les informations qu'il est capable d'obtenir. Le serveur 110 devra ainsi être capable d'identifier l'expéditeur du message, soit par le contenu du message SOAP (qui peut contenir des informations sur le système demandeur), soit par des informations dans les entêtes HTTP (par exemple, l'étiquette "User-agent" normalisée dans le protocole HTTP indique le nom du système client demandeur. Lorsque cette identification est réalisée par le serveur 110, les algorithmes des figures 5 ou 6 sont alors exécutés. Ainsi, lors de la réception d'un message de partage en provenance d'un poste 100, afin de distinguer les deux cas d'usage du message, l'étape suivante 601 consiste à vérifier que la collection Cl à partager est déjà connue du réseau. Si elle ne l'est pas (test 602 négatif), il s'agit d'un partage classique d'une nouvelle collection, illustré par les étapes 610 à 613 décrites plus loin. Si la collection est déjà connue (test 602 positif), il s'agit de mettre à jour la collection du réseau avec les nouvelles informations en provenance du système pair 100 (étapes 603 à 607). En option, cette information de re-partage d'une collection initialement créée à partir d'un client léger 120, peut faire partie du message de partage reçu à l'étape 600. Afin d'assurer un minimum de contrôle d'intégrité et de sécurité, la collection Cl reçue est comparée avec la collection trouvée dans le dispositif de stockage 160: l'auteur doit être le même, ainsi que la liste de diffusion et les images. Cette vérification ne fait pas l'objet de l'invention et n'est pas représentée sur la figure 6. Cependant, elle conditionne l'issue du test 602 qui conduirait à une remontée d'erreur. Dans le cas d'une collection partiellement partagée par un terminal 120, l'étape 603 est exécutée. Le serveur central recherche pour la collection Cl la liste L2 des versions d'images manquantes pour assurer un minimum de qualité de service sur le réseau. En pratique, le serveur 110 doit posséder les imagettes (premier niveau de visualisation d'une image), ce qui a été réalisé préalablement (voir figure 5), mais aussi des versions de résolution supérieure des images: par exemple, on peut se contenter d'un niveau intermédiaire avant la version originale, qui correspondrait à un affichage plein écran 640x480 pixels. Le nombre de niveaux de résolution est donné ici à titre d'exemple non limitatif et la politique de gestion du dispositif de stockage 160 sur le serveur 110 peut comporter un ou plusieurs de ces niveaux de résolution. Ensuite, la liste L2, contenant la liste des identifiants 303 des images ainsi que des versions souhaitées pour ces images, est transmise au poste 100 (étape 604). Au fur et à mesure que les versions des images sont transmises au serveur 110, celui-ci les stocke dans le dispositif de stockage 160. Dans le cas où le serveur a géré un statut de donnée partagée non complète (voir étape 502 de la figure 5), ce statut est supprimé pour chaque nouvelle image dont les versions des résolutions souhaitées ont toutes été reçues. Une condition nécessaire pour la validation de la collection est que toutes les versions des images de L2 soient présentes dans le dispositif de stockage 160 (test 605 positif). La validation consiste aussi à supprimer le label 305 associé aux images 303: cela indique aux pairs destinataires que les données partagées sont maintenant entièrement disponibles sur le réseau. Après avoir validé la collection à l'étape 606, il peut y avoir calcul d'une signature 306 de la collection. La signature peut être calculée par un système classique de signature à clé publique, tel que le RSA: on calcule une empreinte des données à signer (l'auteur, la liste des images 303 et la liste des destinataires 304) par un algorithme tel que MD5 puis cette empreinte est encryptée avec la clé privée du serveur central par le RSA. La signature (et éventuellement les mises à jour effectuées dans la collection) est alors renvoyée au poste pair 100 de l'auteur de la collection. La méthode décrite permet ainsi de garantir l'authenticité de données partagées initialement à partir d'un client léger 120. Une seconde notification est envoyée aux destinataires pour la collection Cl validée (étape 607). Cette notification est spéciale car elle indique aux systèmes pairs la mise à jour d'une collection qu'ils ont déjà reçue ou téléchargée. De préférence, cette notification 607 contient une note explicative permettant aux destinataires de comprendre le changement effectué. Dans le cas où la notification n'inclut pas le fichier de collection Cl, il est à noter que le lien URL indiquant la localisation de ce fichier sur le serveur 110 peut être le même que lors du message de notification de l'étape 506. En option, le serveur central 110 peut demander au système pair 100 d'effectuer cette notification à sa place. Les étapes 610 à 613 décrivent la procédure habituelle pour le partage d'une collection de données numériques créée sur un système pair 100. Le serveur recherche toutes les versions (y compris les imagettes) non localement disponibles dans le dispositif de stockage 160 et nécessaires à sa politique de gestion du cache (étape 610), et demande au poste 100 de les lui fournir (liste L3) (étape 611). En option, le serveur 110 peut aussi demander à tout autre système pair 100 de lui fournir les versions souhaitées. Le système client-serveur 100 partageur est ensuite informé de la procédure à suivre pour conclure la validation de la collection: soit télécharger les 5 versions manquantes, soit directement demander une signature de la collection si toutes les versions étaient déjà présentes. La nouvelle collection est validée (étape 613) à la condition que toutes les versions de L3 soient transmises au serveur central 110 (test 612 positif). Dans un mode de réalisation préféré, la notification unique de partage est réalisée par le poste pair 100. L'organigramme de la figure 7 illustre le fonctionnement du poste pair 100 destinataire d'une collection partagée conformément à l'invention, lorsque l'utilisateur demande la visualisation d'une collection d'images (étape 701). La collection est préalablement chargée à partir de la zone de stockage locale. A la suite de la réception d'une notification, si la collection n'existe pas localement, elle est recherchée sur le réseau P2P et notamment sur le serveur central 110 en utilisant les informations embarquées dans le message de notification. La collection est ensuite analysée (étape 702) afin de détecter la présence éventuelle de labels 305 indiquant que l'image choisie a des propriétés limitées. Si ce label 305 n'est pas trouvé (test 703 négatif), il s'agit d'une image normale et le test 703 conduit à un affichage non limitatif de l'image (étape 705). Au contraire, si le label 305 existe, les actions offertes par l'interface graphique du logiciel P2P du poste 100 doivent être limitées (étape 704). Par exemple, il n'existe qu'une version imagette de l'image sur le réseau et il n'est donc pas souhaitable d'effectuer des opérations de recherche coûteuses dont le système connaît l'issue par avance. Ainsi, des opérations telles que l'impression locale (qui nécessite une version haute résolution), le re-partage dans une nouvelle collection ne sont pas autorisées. De plus, d'un point de vue ergonomique de l'application logicielle, il est préférable d'indiquer par avance à l'utilisateur que l'image courante n'est pas conventionnelle, par exemple par une icône d'interdiction sur l'un des bords de l'image, avec une note explicative: par exemple, lorsque l'utilisateur déplace le curseur de la souris sur l'image, une fenêtre dynamique l'informe que la version originale de l'image, produite à partir d'un appareil photo numérique de son ami, n'a pas encore été introduite dans le réseau P2P. La figure 8 illustre un réseau pair à pair adapté à mettre en oeuvre la présente invention, dans un second mode particulier de réalisation. Il s'agit d'un partage direct entre deux clients légers 120 lors d'une rencontre entre deux utilisateurs A et B. Plus tard, le destinataire B du partage souhaite obtenir par le réseau pair à pair les versions originales des images reçues pour effectuer par exemple des impressions papier. A l'étape 1, la personne A a pris des photographies d'un événement. Elle souhaite partager ses images avec son ami, l'utilisateur B. Ainsi, à l'étape 2, l'utilisateur A sélectionne à partir de son appareil 120-A les images à partager ainsi que l'appareil 120-B de son ami. Par exemple, dans le cas d'un appareil 120 disposant d'une connectivité WiFi, la liste des appareils présents dans le réseau local sans fil est recherchée par l'appareil 120-A afin de pouvoir communiquer avec ceux-ci: ces dispositifs peuvent ensuite s'interroger mutuellement pour connaître les identifiants 304 de leurs possesseurs. En option, les utilisateurs se mettent d'accord sur la version des 20 images à transmettre, sachant que les capacités de bande passante sur le lien local sont sans doute limitées. Le protocole d'échange d'information entre les deux appareils 120-A et 120-B n'est pas le propos de l'invention. Les informations échangées en plus des versions des images concernent les identifiants des utilisateurs 304, un identifiant 302 de collection choisi de préférence par l'appareil 120-A, ainsi que les identifiants 303 pour les images. En option, si l'appareil 120-A ne sait pas créer des identifiants 304 conformes au format du réseau pair à pair, les identifiants 303 sont remplacés par des identifiants propres à l'appareil 120-A. Ensuite, à l'étape 3, l'utilisateur B revient à son domicile et synchronise son appareil 120-B avec son ordinateur PC supportant le logiciel pour se connecter au réseau P2P. Lors de cette synchronisation, le système pair 100-B est notifié par l'appareil 120-B de la présence d'une collection partagée par l'utilisateur A: il s'agit ici aussi d'une notification de la présence d'une collection partielle. Si le poste 100-B est connecté en ligne sur le réseau P2P, une recherche peut être réalisée vers le serveur central 110 afin de tenter de récupérer la collection (au cas où l'utilisateur A se serait synchronisé avant B). Si la recherche échoue et/ou si le poste 100-B n'est pas connecté, celui-ci tente de re-créer localement, avec les informations dont il dispose, une collection correspondant au partage des images qu'il vient d'obtenir de l'appareil 120-B. Comme il s'agit d'une collection dont l'auteur n'est pas local au pair (A est l'auteur) et dont l'existence sur le réseau n'est pas prouvée, cette collection se voit attribuer un statut de collection partielle: le poste 100-B ou le mobile 120-B (avant la première notification au poste 100-B) construit la collection en attribuant un label 305 aux images de la collection. Cela permettra de limiter l'impact d'actions inutiles sur le réseau (recherches, etc.) tant qu'une seconde notification ne sera pas reçue. L'utilisateur B est alors capable de visualiser localement en basse résolution (du moins, à la résolution choisie lors de l'échange entre les appareils 120-A et 120-B) la collection Cl d'images de son ami A sur son ordinateur. Plus tard, l'utilisateur B sera averti de la présence des images originales. A l'étape 4, lorsque l'utilisateur A connecte son appareil léger 120-A sur son ordinateur 100-A relié au réseau P2P, une synchronisation locale est exécutée entre l'appareil 120-A et le poste 100-A comme décrit précédemment à l'étape 4 de la figure 4. Cette synchronisation est suivie d'un partage de la collection vers le serveur 110 (étape 5). L'utilisateur A est autorisé à ajouter des informations supplémentaires qui n'ont pas pu être saisies au préalable à partir de l'appareil 120-A, telles que, par exemple, un titre plus personnalisé ou des légendes pour les images sélectionnées. A la réception de ce message à l'étape 5, le serveur central 110 ne dispose pas d'une collection partielle, auquel cas il exécute les actions décrites aux étapes 610 à 613 de la figure 6. A l'étape 6, à l'issue de ce partage de forme classique, une notification est envoyée aux destinataires (ici l'utilisateur B) pour les informer du partage sur le réseau: il s'agit ici de la notification d'une collection complète. Dans un mode particulier de réalisation, cette notification est effectuée par le poste pair 100-A car celui-ci sait que la collection provient d'un échange entre des appareils 120, et le message accompagnant la notification peut être explicité pour indiquer qu'il s'agit d'une mise à jour d'une collection dont la disponibilité des contenus est maintenant totale. En option, le serveur central 110 peut être renseigné sur le statut de 10 la collection qu'il reçoit, afin de proposer une note d'information adéquate (par exemple, "collection reçue de A à partir de son appareil photo"). La figure 9 illustre un réseau pair à pair adapté à mettre en oeuvre la présente invention, dans des variantes de réalisation. Les étapes numérotées 1 à 6 illustrées sur cette figure étant analogues aux étapes illustrées sur la figure 4 portant les mêmes numéros, elles ne sont pas décrites en détail une nouvelle fois. Toutefois, la figure 9 illustre des scénarios ne faisant pas intervenir d'appareil mobile (ou client léger). La figure 9 illustre un premier cas où les pairs 100-A et 100-B sont des machines distinctes. Un utilisateur du service P2P crée une collection d'images sur le poste pair 100-A d'un ami, ou sur sa propre machine professionnelle, sur son lieu de travail, mais ne souhaite pas utiliser ce poste 100-A comme serveur. Il n'envoie, à l'étape 2, que les données nécessaires à la création de la collection partielle. Les images d'origine sont stockées sur un disque amovible. Puis de retour chez lui, sur son poste personnel 100-B, cet utilisateur synchronise à l'étape 4 le disque amovible avec son ordinateur 100-B, qui met à disposition du réseau P2P les versions haute résolution des données. La figure 9 illustre également un second cas où les pairs 100-A et 100-B sont une seule et même machine. L'étape 4 est dans ce cas une relation temporelle: à un instant t, le pair 100-A/1 00-B décide de créer une collection à partager rapidement et n'envoie sur le réseau que des données succinctes. Plus tard, sur réveil d'une minuterie ou sur exécution d'une commande de l'utilisateur, le pair 100-A/100-B envoie sur le réseau des données manquantes. Dans les deux cas décrits précédemment, le pair 100-A est capable de créer une collection et d'envoyer directement la première notification aux pairs 100 destinataires à l'étape 3. Le pair 100-B est capable de mettre à jour cette collection et d'envoyer une seconde notification aux pairs 100 destinataires, à l'étape 6. REVENDICATIONS 1. Procédé de partage de données numériques dans un réseau de communication pair à pair, suivant lequel on transmet, à des postes 5 destinataires desdites données, dans un premier temps, une version partielle des données partagées, ledit procédé étant caractérisé en ce qu'il comporte des étapes suivant lesquelles: - on crée (501) une collection de données (300), dans laquelle on associe un identifiant (303) à chaque donnée et on attribue (507) à chaque 10 identifiant de donnée un label (305) indiquant si la version complète de la donnée est disponible sur le réseau; - on notifie (étape 3 de la figure 4; 506) à au moins un poste destinataire l'existence de ladite collection (300) ; et à réception d'informations de disponibilité sur le réseau des versions complètes 15 des données de la collection (300) : - on met à jour ladite collection (300) ; et - on notifie (étape 6 de la figure 4) audit au moins un poste destinataire la mise à jour de la collection partagée. 2. Procédé selon la revendication 1, caractérisé en ce que ladite 20 collection de données (300) est constituée: - d'un en-tête (300H), comportant un titre (301), un identifiant (302) de collection et un identifiant (304) de l'auteur de la collection, et - d'un corps (300B), comportant une pluralité d'identifiants (303) des données numériques de la collection, et une pluralité de labels (305) respectivement associés aux identifiants (303) des données, chaque label (305) indiquant si la version complète de la donnée est disponible sur le réseau. 3. Procédé selon la revendication 2, caractérisé en ce que l'en-tête (300H) de ladite collection de données (300) comporte en outre une signature 30 (306). 4. Procédé selon la revendication 2 ou 3, caractérisé en ce que le corps (300B) de ladite collection de données (300) comporte en outre une pluralité d'identifiants (304) d'utilisateurs autorisés à accéder à ladite collection. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque label (305) est un drapeau dont la présence indique que la version complète de la donnée correspondante n'est pas disponible sur le réseau et dont l'absence indique que la version complète de la donnée est disponible sur le réseau. 6. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que chaque label (305) est un booléen dont la valeur indique la présence ou l'absence de la donnée correspondante sur le réseau. 7. Procédé selon la revendication 5, caractérisé en ce que l'étape de mise à jour de la collection consiste à supprimer les labels (305) correspondant aux données dont la version complète est disponible sur le réseau. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les données représentent des images numériques fixes et la version partielle d'une donnée est une version d'une image ayant une résolution inférieure à celle de l'image d'origine. 9. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que les données représentent une vidéo numérique et la version partielle d'une donnée est la première image de la vidéo à une résolution inférieure à celle de la vidéo d'origine. 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les étapes dudit procédé sont mises en oeuvre par un 25 serveur central (110). 11. Procédé selon la revendication précédente, caractérisé en ce qu'on crée la collection de données (300) à réception d'une requête de partage de données numériques en provenance d'une station mobile (120). 12. Procédé selon la revendication précédente, caractérisé en ce que la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après connexion de ladite station mobile (120) avec un poste pair du réseau et sur synchronisation de la collection (300) entre ladite station mobile et ledit poste pair. 13. Procédé selon la revendication 10, caractérisé en ce qu'on crée la collection de données (300) à réception d'une requête de partage de données numériques en provenance d'un premier poste pair du réseau. 14. Procédé selon la revendication précédente, caractérisé en ce que la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après mise à disposition de versions complètes des données par un deuxième poste pair du réseau. 15. Procédé selon la revendication 13, caractérisé en ce que la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après mise à disposition de versions complètes des données par ledit premier poste pair après un temps prédéterminé. 16. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que les étapes de création de la collection (300) et de notification de l'existence de la collection sont mises en oeuvre par une station mobile, les étapes de mise à jour de la collection et de notification de mise à jour de la collection étant effectuées par une station pair du réseau ou par un serveur central. 17. Procédé selon la revendication précédente, caractérisé en ce que la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après connexion de ladite station mobile avec un poste pair du réseau et sur synchronisation de la collection entre ladite station mobile et ledit poste pair. 18. Procédé selon la revendication 16, caractérisé en ce qu'on crée ladite collection de données (300) à réception d'une requête de partage de données numériques en provenance d'une seconde station mobile. 19. Procédé selon la revendication précédente, caractérisé en ce que la réception d'informations de disponibilité sur le réseau des versions complètes des données s'effectue après connexion de ladite seconde station mobile avec un poste pair du réseau et sur synchronisation de la collection entre ladite seconde station mobile et ledit poste pair. 20. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que les étapes de création de la collection (300) et de notification de l'existence de la collection sont mises en oeuvre par une station pair du réseau, les étapes de mise à jour de la collection et de notification de mise à jour étant effectuées par une autre station pair du réseau. 21. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'ensemble des étapes dudit procédé est mis en oeuvre par une station pair du réseau. 22. Procédé de partage de données numériques dans un réseau de communication pair à pair, suivant lequel on transmet, à des postes destinataires desdites données, dans un premier temps, une version partielle des données partagées, ledit procédé étant caractérisé en ce qu'il comporte des étapes suivant lesquelles, au niveau d'un poste destinataire: à réception d'une notification indiquant l'existence d'une collection de données (300) comportant un identifiant (303) associé à chaque donnée, un label (305) ayant été attribué à chaque identifiant de donnée pour indiquer si la version complète de la donnée est disponible sur le réseau, - on analyse les labels associés aux identifiants de données de la collection; - en cas d'existence de labels indiquant que la version complète d'une donnée n'est pas disponible sur le réseau, on restreint (704) les droits de traitement associés à ladite donnée; et - à réception d'une notification de mise à jour de la collection, on supprime la restriction des droits de traitement. 23. Procédé selon la revendication précédente, caractérisé en ce qu'il comporte en outre une étape d'affichage des restrictions des droits de traitement. 24. Procédé selon la revendication 22 ou 23, caractérisé en ce que la restriction des droits de traitement est une interdiction de demande de version complète de la donnée et/ou une interdiction d'impression de la donnée si la donnée est une image et/ou une interdiction d'un nouveau partage de cette donnée. 25. Dispositif de partage de données numériques dans un réseau de communication pair à pair, dans lequel des postes destinataires desdites données sont adaptés à recevoir, dans un premier temps, une version partielle des données partagées, ledit dispositif étant caractérisé en ce qu'il comporte: - des moyens pour créer une collection de données (300), dans laquelle un identifiant (303) est associé à chaque donnée et un label (305) est attribué à chaque identifiant de donnée, ledit label indiquant si la version complète de la donnée est disponible sur le réseau; - des moyens pour notifier à au moins un poste destinataire l'existence de ladite collection (300) ; - des moyens pour mettre à jour ladite collection (300) ; et - des moyens pour notifier audit au moins un poste destinataire la mise à jour de la collection partagée. 26. Dispositif selon la revendication 25, caractérisé en ce que ladite collection de données (300) est constituée: - d'un en-tête (300H), comportant un titre (301), un identifiant (302) de collection et un identifiant (304) de l'auteur de la collection, et - d'un corps (300B), comportant une pluralité d'identifiants (303) des données numériques de la collection, et une pluralité de labels (305) respectivement associés aux identifiants (303) des données, chaque label (305) indiquant si la version complète de la données est disponible sur le réseau. 27. Dispositif selon la revendication 26, caractérisé en ce que l'en-tête (300H) de ladite collection de données (300) comporte en outre une signature (306). 28. Dispositif selon la revendication 26 ou 27, caractérisé en ce que le corps (300B) de ladite collection de données (300) comporte en outre une pluralité d'identifiants (304) d'utilisateurs autorisés à accéder à ladite collection. 29. Dispositif selon l'une quelconque des revendications 25 à 28, caractérisé en ce que chaque label (305) est un drapeau dont la présence indique que la version complète de la donnée correspondante n'est pas disponible sur le réseau et dont l'absence indique que la version complète de la donnée est disponible sur le réseau. 30. Dispositif selon l'une quelconque des revendications 25 à 28, caractérisé en ce que chaque label (305) est un booléen dont la valeur indique la présence ou l'absence de la donnée correspondante sur le réseau. 31. Dispositif selon la revendication 29, caractérisé en ce que les moyens de mise à jour de la collection sont adaptés à supprimer les labels (305) correspondant aux données dont la version complète est disponible sur le réseau. 32. Dispositif selon l'une quelconque des revendications 25 à 31, caractérisé en ce que les données représentent des images numériques fixes et la version partielle d'une donnée est une version d'une image ayant une résolution inférieure à celle de l'image d'origine. 33. Dispositif selon l'une quelconque des revendications 25 à 31, caractérisé en ce que les données représentent une vidéo numérique et la version partielle d'une donnée est la première image de la vidéo à une résolution inférieure à celle de la vidéo d'origine. 34. Dispositif selon l'une quelconque des revendications 25 à 33, caractérisé en ce que les moyens de création de la collection (300) sont adaptés à créer la collection de données (300) à réception d'une requête de partage de données numériques en provenance d'une station mobile (120). 35. Dispositif selon l'une quelconque des revendications 25 à 33, caractérisé en ce que les moyens de création de la collection (300) sont adaptés à créer la collection de données (300) à réception d'une requête de partage de données numériques en provenance d'un premier poste pair du réseau. 36. Dispositif de partage de données numériques dans un réseau de communication pair à pair, dans lequel des postes destinataires desdites données sont adaptés à recevoir, dans un premier temps, une version partielle des données partagées, ledit dispositif étant caractérisé en ce qu'il comporte, au niveau d'un poste destinataire: - des moyens pour analyser, à réception d'une notification indiquant l'existence d'une collection de données (300) comportant un identifiant (303) associé à chaque donnée, un label (305) ayant été attribué à chaque identifiant de donnée pour indiquer si la version complète de la donnée est disponible sur le réseau, les labels associés aux identifiants de données de la collection; - des moyens pour restreindre les droits de traitement associés à ladite donnée en cas d'existence de labels indiquant que la version complète d'une donnée n'est pas disponible sur le réseau; et -des moyens pour supprimer la restriction des droits de traitement à réception d'une notification de mise à jour de la collection. 37. Dispositif selon la revendication précédente, caractérisé en ce qu'il comporte en outre des moyens d'affichage des restrictions des droits de traitement. 38. Procédé selon la revendication 36 ou 37, caractérisé en ce que la restriction des droits de traitement est une interdiction de demande de version complète de la données et/ou une interdiction d'impression de la donnée si la donnée est une image et/ou une interdiction d'un nouveau partage de cette donnée. 39. Serveur de données dans un réseau de communication pair à 20 pair, comportant: - des moyens (160) de stockage de données; - un serveur Web (150) ; - une interface de visualisation (140), couplée audit serveur Web (150), et - une base de données (180), ledit serveur étant caractérisé en ce qu'il est adapté à exécuter un logiciel (130) qui met en oeuvre un procédé selon l'une quelconque des revendications 1 à 24. 40. Moyen de stockage d'informations lisible par un ordinateur ou un 30 microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 24. 41. Moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 24. 42. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé selon l'une quelconque des revendications 1 à 24, lorsque ce programme est chargé et exécuté par l'appareil programmable.