Brevet FR2857763A1 — publié le 20050121

La présente invention se rapporte à l'accès et/ou au partage d'un document numérique disponible dans un réseau de communication reliant des dispositifs clients entre eux, ledit procédé utilisant une notification indiquant la présence d'un document numérique disponible sur le réseau, la notification étant apte à s'adapter et à exploiter la présence ou non d'une application locale susceptible de traiter le document numérique. Elle trouve une application générale dans le traitement des documents numériques disponibles dans un réseau de communication, notamment dans les réseaux de communication de type pair à pair, appelés encore poste à poste, peer to peer, et désignés ci-après par l'acronyme P2P. Les systèmes de communication P2P ont émergé ces dernières années constituant une révolution dans le partage de fichier en comparaison du modèle traditionnel client serveur. Dans les systèmes P2P, chaque machine (on parle aussi de node ou peer) constituant le réseau de communication se comporte aussi bien en dispositif client qu'en dispositif serveur. Ainsi, dans un réseau P2P, les équipements mettent en commun des ressources selon une philosophie de partage d'égal à égal, chaque machine d'un réseau P2P se comportant aussi bien en client qu'en serveur. De tels réseaux se distinguent ainsi des réseaux clients serveurs classiques dans lesquels les ressources sont archivées dans un dispositif serveur central. Actuellement, la distribution des données fait de plus en plus appel aux réseaux P2P en raison de leur mise en place peu coûteuse, de la présence de très nombreux ordinateurs connectés sur les réseaux, ainsi que du développement des connexions haut débit. Cependant, les réseaux P2P sont instables. En effet, les dispositifs clients (et par conséquent des dispositifs serveurs) se connectent ou se déconnectent périodiquement sur le réseau, rendant ainsi la présence des données très aléatoires. De plus, les adresses des dispositifs clients et/ou serveurs sont imprédictibles et susceptibles d'être différentes à chaque connexion. De par leur spécificité, les systèmes P2P impliquent généralement l'utilisation d'une application cliente, locale, dédiée, appelée encore application locale P2P. Une telle application locale P2P assure le partage du contenu numérique, ainsi que la recherche et l'accès au contenu numérique disponible sur les réseaux P2P. Par exemple, l'application locale P2P peut offrir un mécanisme de notification basé sur l'échange de messages suivant un protocole propriétaire afin de permettre à un dispositif client de notifier une ou plusieurs personnes qu'il vient de partager de nouveaux contenus numériques sur le réseau. L'application locale P2P peut également utiliser le courrier électronique comme mécanisme principal d'une notification ou comme un complément au système de notification propriétaire. Dans ce cas, le courrier électronique peut éventuellement contenir en attachement un ou plusieurs fichiers spécifiques qui pourront être interprétés par l'application locale P2P chez le ou les destinataires. On connaît aussi des systèmes P2P qui permettent à des utilisateurs ne possédant pas d'application locale P2P, d'accéder au contenu sur le réseau à l'aide d'outils d'accès à l'Internet plus traditionnels et répandus tels que les explorateurs, butineurs, ou navigateurs Internet. Dans de tels systèmes, certains dispositifs clients ou dispositifs serveurs spécifiques dans le réseau se comportent comme des dispositifs serveurs jouant le rôle de passerelle entre l'outil d'accès à Internet (butineur, explorateur, navigateur) et le réseau P2P. Ces machines peuvent être vues comme des dispositifs serveurs mandataires (Proxy en anglais) qui se chargent de récupérer la ressource recherchée sur le réseau P2P pour le compte de l'outil Internet. Dans ces systèmes, le courrier électronique est classiquement utilisé comme mécanisme de notification. Le courrier électronique peut alors contenir une page en langage de balisage ou un lien (appelé aussi URL de l'anglais "Uniform Ressource Locator") vers une page permettant à l'utilisateur destinataire d'accéder aux ressources. Ainsi, dans un système P2P, un utilisateur peut utiliser une application locale P2P pour partager des contenus numériques sur le réseau, parcourir et accéder au contenu disponible sur le réseau P2P. L'utilisateur ne possédant pas l'application locale P2P ou celui ne souhaitant pas utiliser l'interface proposée peut également utiliser des outils capables de visualiser des pages en langage de balisage pour accéder au contenu numérique (Navigateur Web, lecteur de courrier électronique, ou tout autre application capable d'afficher des pages en langage de balisage). Par exemple, l'utilisateur peut partager des collections de contenus numériques avec un ensemble de personnes, ces personnes pouvant posséder ou non l'application locale P2P. Le Demandeur s'est posé le problème de fournir un procédé permettant de notifier les dispositifs clients destinataires d'une manière uniforme sans savoir à priori si lesdits destinataires possèdent une application locale P2P dédiée au traitement des documents numériques. La présente invention apporte justement une solution à ce problème. Elle porte sur un procédé d'accès à au moins un document numérique disponible dans un réseau de communication reliant des dispositifs clients entre eux, ledit procédé d'accès étant mis en oeuvre au sein d'un dispositif client destinataire. Selon une définition générale de l'invention, le procédé comprend les étapes suivantes : - i) recevoir une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique ; - ii) exécuter la ou les commandes afin de détecter la présence et l'activation de l'application locale ; et - iii) en cas d'application locale présente et active, accéder au document numérique à partir d'un serveur local tandis qu'en cas d'absence ou d'inactivité de l'application locale, accéder au document à partir d'un serveur distant. Ainsi, le procédé notifie de manière uniforme les utilisateurs d'un réseau qui possèdent ou non l'application locale. Plus particulièrement, le procédé optimise l'usage du réseau au travers de la notification en cherchant à permettre l'usage de l'application locale pour la visualisation des documents numériques dès que cette application est disponible chez l'utilisateur tout en restant compatible avec ceux ne possédant pas cette application locale. Ainsi, il est prévu de modifier l'information contenue dans la notification lors de sa visualisation en fonction de la présence ou non de l'application locale chez le destinataire. En pratique, la notification comprend, en outre, une page en langage de balisage contenant au moins un identifiant désignant le document numérique, et une adresse distante désignant un serveur distant. Selon une réalisation, le procédé comprend en outre, à l'issue de l'étape ii) et avant l'étape iii), l'étape iia) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder à l'activation de l'application locale à la suite d'une autorisation de l'utilisateur du dispositif client destinataire accordée en réponse à une commande exécutable choisie. En variante, à l'issue de l'étape ii) et avant l'étape iii), le procédé comprend en outre l'étape iib) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder automatiquement à l'activation de l'application locale conformément à une commande exécutable choisie. Selon une autre réalisation, le procédé comprend en outre, après l'étape iii), l'étape iv) dans laquelle, en cas d'application locale présente et active, il est prévu de vérifier la présence du document dans un serveur local, et en cas de vérification négative de rechercher ledit document dans le réseau, de le télécharger en cas de recherche positive, et de le sauvegarder localement avant de le servir en réponse à la requête d'accès. Selon une autre réalisation, en cas d'application locale présente et active, il est prévu d'adapter localement la page en langage de balisage de manière à accéder au document à partir de l'adresse d'un serveur local. En pratique, l'adaptation de la page comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur local. Selon encore une autre réalisation, en cas d'application locale absente ou inactive, il est prévu d'adapter localement la page en langage de balisage de manière à accéder au document à partir de l'adresse d'un serveur distant. En pratique, l'adaptation de la page comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur distant. En pratique, le réseau de communication est de type poste à poste, centralisé, décentralisé ou hybride. Par exemple, la page est écrite en langage de balisage de type HTML ou analogue, la ou les commandes incluses dans la page en langage de balisage faisant appel à un programme local du type activeX ou analogue, apte à déterminer la présence et l'activation d'un serveur local, ainsi qu'à récupérer les paramètres de configuration dudit serveur local. Par exemple, la ou les commandes exécutables sont de type programme Script tel que Java Script ou VB Script, la ou lesdites commandes étant embarquées dans la page ainsi notifiée. Par exemple, l'adresse locale désignant un serveur local est déterminée par le programme Script apte à récupérer les paramètres de configuration dudit serveur local. La commande comprend en outre une fonction apte à pointer une adresse locale ou distante permettant d'accéder au document. En pratique, la page est notifiée en attachement avec un courrier électronique. Selon une variante de réalisation, la page est téléchargée sur un serveur distant choisi et une référence à cette page est envoyée à tout destinataire à notifier, la référence de la page étant, par exemple, de type URL, incluse dans un courrier électronique. La présente invention a également pour objet un procédé de partage d'un document numérique dans un réseau de communication reliant des dispositifs clients entre eux, ledit procédé étant mis en oeuvre au sein d'un dispositif client émetteur. Selon un autre aspect de l'invention, le procédé comprend l'étape suivante : - émettre à destination d'au moins un dispositif client destinataire une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, et en cas d'application locale présente et active, à accéder au document à partir de l'adresse d'un serveur local sinon à accéder au document à partir de l'adresse d'un serveur distant. La présente invention a également pour objet un dispositif d'accès à au moins un document numérique apte à mette en #uvre le procédé d'accès selon l'invention. De même, la présente invention a également pour objet un dispositif de partage d'un document numérique apte à mettre en #uvre le procédé de partage mentionné ci avant. La présente invention a également pour objet un support d'informations lisible par un système informatique, éventuellement amovible totalement ou partiellement, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en #uvre du procédé conforme à l'invention, lorsque le programme est chargé et exécuté par un système informatique. Enfin, la présente invention a également pour objet un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en #uvre d'un procédé au traitement conforme à l'invention, lorsque ce programme est chargé et exécuté par un système informatique. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels : - la figure 1 représente schématiquement les éléments essentiels d'un dispositif client destinataire apte à mettre en #uvre le procédé d'accès selon l'invention ; - la figure 2 représente schématiquement un réseau de communication reliant des dispositifs clients entre eux selon l'invention ; - la figure 3 est un organigramme illustrant les étapes relatives à la visualisation d'une page en langage de balisage selon l'invention ; - la figure 4 est un organigramme illustrant les étapes relatives à la vérification de l'activation de l'application locale selon l'invention ;et - la figure 5 est un organigramme illustrant le comportement d'un serveur local selon l'invention. En référence à la figure 1, un appareil mettant en #uvre l'invention est par exemple un micro ordinateur 10 ou une station de travail connectée à différents éléments périphériques tels que par exemple une caméra numérique 11 (ou un scanner, ou tout autre moyen d'acquisition ou de stockage de documents numériques tels que par exemple des images) relié à une carte d'entrée/sortie (non représentée) et fournissant à l'appareil des données multimédia. L'appareil 10 comporte un bus de communication 101 auquel sont reliés plusieurs éléments tels que : - une unité centrale de traitement 102 (microprocesseur, noté CPU sur la figure 1) ; - une mémoire morte 103 pouvant comporter des programmes suivant l'invention ; - une mémoire vive 104, qui après la mise sous tension, contient le code exécutable du procédé suivant l'invention ainsi que des registres adaptés à enregistrer des variables et paramètres nécessaires à la mise en #uvre de l'invention ; - un écran 105 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 106 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 107 ou un crayon optique (non représenté) ; - un disque dur 108 pouvant comporter les programmes selon l'invention ainsi que des données utilisées ou produites lors de la mise en #uvre de l'invention ; - un lecteur de disquettes 109 adapté à recevoir une disquette 12 et à lire ou à y écrire des données traitées ou à traiter selon l'invention ; et - une interface de communication 110 reliée à un réseau de communication 13, l'interface étant apte à transmettre et à recevoir des données. Dans le cas de données audio, l'appareil 10 peut comprendre en outre une carte entrée/sortie (non représentée) reliée à un microphone 14. Le bus de communication 101 permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil 10 ou relié à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil 10 directement ou par l'intermédiaire d'un autre élément de l'appareil 10. Les disquettes 12 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en #uvre du procédé selon l'invention. Le code exécutable, permettant à l'appareil la mise en #uvre de l'invention, peut se trouver indifféremment stocké en mémoire morte 103, sur le disque dur 108 ou sur un support numérique amovible tel que par exemple une disquette 12 telle que décrite précédemment. Selon une variante, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 13, via l'interface 110, pour être stocké dans un des moyens de stockage de l'appareil 10 avant d'être exécuté (tel que le disque dur 108 par exemple). L'unité centrale 102 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans l'un des moyens 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 108 ou la mémoire morte 103, sont transférés dans la mémoire vive 104 (RAM) qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en #uvre de l'invention. Il convient de noter que l'appareil comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC). En référence à la figure 2, un réseau de communication 13 relie entre eux plusieurs dispositifs clients ou terminaux, individualisés en client1 21, client2 22, et client3 23. Chaque dispositif client peut être relié au réseau 13 par des moyens de communications différents tels que des moyens de communication haut débit ou bas débit (modem xDSL, PSTN ou câble). Le réseau 13 peut tout aussi bien être constitué au-dessus du réseau Internet qu'au-dessus d'un réseau local privé (de l'anglais Local Area Network (LAN) ) ou d'une combinaison des deux. Les terminaux des dispositifs clients se décomposent en deux catégories distinctes. Il s'agit soit de terminaux munis de l'application P2P pair-à-pair dédiée (client2 et client1 ) soit de terminaux non munis de cette application P2P pair-à-pair dédiée (client3). Les terminaux munis de l'application P2P pair-à-pair dédiée forment entre eux un réseau de communication de type P2P pair-à-pair au travers du réseau de communication 13 et suivant une des topologies connus de l'homme du métier (centralisé, décentralisé avec ou sans serveur central superpeers ou encore hybrides). L'application P2P pair-à-pair comporte au moins un module serveur portant la référence 218 dans le dispositif client 21 ou la référence 228 dans le dispositif client 22. L'application P2P comprend en outre un moyen de stockage ou cache 217, 226. Le module serveur 218 ou 228 est chargé de répondre aux requêtes d'accès aux ressources pair-à-pair . Les requêtes peuvent provenir aussi bien d'applications distantes que d'applications présentes sur la même machine que le serveur. Les requêtes peuvent être aussi bien reçues suivant un protocole propriétaire propre à l'application pair-à-pair que suivant le protocole HTTP (de l'anglais Hyper Text Transfer Protocol ) communément utilisé sur l'Internet. Le moyen de stockage 217, 226 contient les contenus numériques partagés sur le réseau pair-à-pair à l'aide du module serveur 218,228. L'application pair-à-pair peut également être complétée par une application locale cliente, dédiée, P2P (219,229) offrant une interface à l'utilisateur lui permettant de rechercher, d'accéder, de visualiser et de partager des contenus numériques sur le réseau pair-à-pair . Tous les terminaux, qu'ils soient munis ou non de l'application pair-à-pair dédiée, peuvent également utiliser des outils (227,237) capables de visualiser des pages en langage de balisage de type HTML pour accéder aux contenus numériques à l'aide du protocole de communication HTTP. Un ou plusieurs serveurs proxy/passerelle spécifiques 24 peuvent également être connectés au réseau 13, ces serveurs offrent un point d'entrée sur le réseau pair-à-pair pour les clients ne possédant pas de clients pair-à-pair dédiés et utilisant le protocole de communication HTTP. Quand ils reçoivent une requête pour une ressource du réseau pair-à-pair , les serveurs proxy 24 déterminent une ou plusieurs machines du réseau pair-à-pair susceptible d'avoir la ressource demandée et se chargent soit de rediriger le demandeur vers une de ces machines, soit de récupérer la ressource auprès d'une de ces machines pour le compte du demandeur pour ensuite la lui servir tel un serveur de type proxy. Il est à noter que ce rôle de serveur proxy/passerelle peut également être tenu par les dispositifs clients eux-mêmes s'ils ont l'application dédiée pair-à-pair comme, par exemple, les dispositifs clients 1 et 2 respectivement numérotés 21 et 22. Suivant l'invention, si l'utilisateur connecté sur la machine 21 souhaite partager une nouvelle collection de contenus numériques composée des images individualisées en image1, image2 et image3 présentes sur son disque 217 avec les clients 22 et 23, il utilise l'application locale P2P 219 pour créer et partager une nouvelle collection composée de ces trois images. Durant le partage, l'application locale P2P 219 associe à chaque image un identifiant unique Imagel ID, Image2 ID, Image3 ID. Des outils bien connus de l'homme de l'art permettent de générer des identifiants avec une infime probabilité de duplication. Après l'opération de partage proprement dite et propre à l'application pair-à-pair , l'application locale P2P 219 génère une page en langage de balisage HTML 25 décrivant la nouvelle collection afin de notifier les clients 22 et 23 qu'une nouvelle collection de contenus numériques est disponible sur le réseau. Cette page HTML contient au moins des scripts 252 tels que par exemple des javaScripts et une référence pour chacun des identifiants de contenus numériques nouvellement partagés 253. Une fois que la page HTML 25 a été générée, l'utilisateur peut envoyer cette page à toutes les personnes qu'il souhaite notifier de l'existence des nouveaux contenus numériques partagés (dans notre exemple le client2 et client3). Dans le mode de réalisation préféré, l'utilisateur envoie la page HTML 25 en la mettant en attachement à un courrier électronique. Dans un autre mode de réalisation, l'utilisateur télécharge la page HTML 25 sur un serveur tel que le serveur 24. En outre, l'utilisateur envoie une référence désignant cette page HTML sur ledit serveur à toutes les personnes qu'il souhaite notifier, par exemple sous la forme d'une URL incluse dans un courrier électronique. Les destinataires téléchargent la page HTML 25 à partir du serveur 24 à l'aide de la référence (ladite URL) reçue en notification. L'utilisateur peut aussi bien utiliser tout autre moyen permettant de transmettre la page HTML à des destinataires (par exemple en utilisant un système d'échange de fichier pair-à-pair , en envoyant par la poste une disquette contenant la page HTML, ...). Quand la page HTML 25 est reçue et affichée par les destinataires à l'aide des applications 227 et 237, c'est-à-dire un navigateur Internet, un lecteur de courrier électronique ou toute autre application capable d'interpréter et d'afficher une page HTML, le contenu de la page est interprété et les codes exécutables (scripts) contenu dans la page sont exécutés. Un premier code est chargé de déterminer si l'application locale P2P pair-à-pair dédiée est installée. Si l'application dédiée est installée, le premier code récupère à l'aide d'un deuxième code externe à la page HTML (ex : activeX) des informations de configuration sur l'application pair-à-pair telles que par exemple les numéros de ports réseaux utilisés par l'application. Puis, le premier code initialise des variables qui sont utilisées par un troisième code embarqué dans la page HTML 25 et chargé de générer les adresses URL à utiliser pour accéder aux contenus numériques. Le troisième code est appelé lors de l'interprétation de la page HTML pour chacune des références sur les contenus numériques partagés. Si le serveur local pair-à-pair 228 a été détecté par le premier code comme installé et actif, le troisième code retourne du code HTML dont les URLs sont dirigées vers le serveur local pair-à-pair (cas C1 pour le client 2 sur la figure 2). Les URLs retournées pourront être de la forme http://localhost:80/RUID où RUID représente l'identifiant unique de la ressource partagée. Si le serveur local pair-à-pair 228 n'est pas présent sur la machine 22 ou n'est pas actif, le troisième code retourne du code HTML dont les URLs sont dirigées vers un serveur distant prédéfini offrant une passerelle entre des requêtes web http et le réseau pair-à-pair tel que par exemple le serveur proxy/passerelle web/ pair-à-pair 24 (cas du client 3 et cas C2 pour le client 2 sur la figure 2). Les URLs retournées peuvent être de la forme http://www.server.com/RUID où www. server.com représente l'adresse web du serveur 24 et RUID représente l'identifiant unique de la ressource partagée. L'invention permet ainsi d'adapter le contenu de la notification (page HTML 25) selon que le destinataire possède ou non l'application pair-àpair . Dans notre exemple, le dispositif client3 23 ne possède pas l'application pair-à-pair . Dans son cas, tous les accès sur les contenus numériques partagés sont donc dirigés vers le serveur proxy 24. Par contre, pour le dispositif client2 22 les accès aux contenus numériques sont dirigés vers son serveur pair-à-pair 228 s'il est actif (cas C1) et vers le serveur proxy 24 s'il est inactif (cas C2). Les avantages d'utiliser le serveur pair-à-pair dès qu'il est disponible sont notamment le fait de ne pas faire des accès réseaux si les données sont déjà présentes dans le cache du serveur pair-à-pair . De plus, si les contenus numériques sont accédés au travers du serveur local pair-àpair , lesdits contenus sont alors présents dans le cache du serveur et peuvent ainsi être servis à des machines distantes en retour. On augmente ainsi le nombre de machines dans le réseau pair-à-pair pouvant servir un contenu numérique donné. Les machines pouvant être à tout moment déconnectées, on augmente ainsi la probabilité de trouver un contenu numérique donné dans le réseau à tout instant. En référence à la figure 3, on a représenté un organigramme illustrant le comportement du script chargé de déterminer si un serveur local pair-à-pair est présent et actif sur la machine. Ce script est intégré à la page HTML 25 soit sous la forme d'un script 252 délimité par les balises HTML et où ### indique le langage utilisé ou soit sous la forme d'une référence à un fichier externe. Le script est interprété et exécuté à chaque affichage de la page HTML. A l'étape E302, le script commence par vérifier si l'application pair-à-pair est installé ou non sur la machine. Pour cela, il cherche à détecter la présence d'un programme activeX ou d'un module d'extension (plug-in) faisant partie de l'application pair-à-pair . Par exemple, si le programme à détecter est un activeX, il peut appeler la fonction définie par le programme VBscript suivant : Cette fonction detectActiveXControl prend en paramètre le nom de l'activeX et retourne True si l'activeX est présent sur la machine et False sinon. A l'étape E303, si l'application a été détectée comme non présente sur la machine, l'algorithme passe à l'étape E308 et positionne une variable indiquant qu'il faut utiliser dans la suite du traitement de la page HTML des URLs dirigées vers le serveur distant 24. Si au contraire, l'application P2P a été détectée, le script détermine à l'étape E304 si le serveur local pair-à-pair 228 est actuellement actif (c'est-à-dire en cours d'exécution) ou non. Pour cela, il utilise le programme activeX détecté à l'étape précédente pour récupérer la configuration courante du serveur pair-à-pair 228 en consultant soit les registres soit un fichier de configuration. Par exemple, le programme activeX récupère le numéro de port réseau sur lequel le serveur 228 est en écoute. Si celui-ci est inactif, le port vaut zéro. Si la valeur est différente de zéro, à l'étape E309, il positionne une variable contenant le numéro de port sur lequel le serveur 228 est en écoute. A l'étape E310, le script positionne une variable indiquant qu'il faut utiliser dans la suite du traitement de la page HTML 25 des adresses URLs dirigés vers le serveur local 228 pour accéder aux contenus numériques. Par exemple si GetRegValue est une fonction de l'activeX MpActiveXVB permettant d'accéder au registre, le programme suivant peut être utilisé pour déterminer si le serveur local est actif ou non et récupérer son numéro de port (étape E304 et E309). LocalServerPort = MpActiveXVB.GetRegValue("SOFTWARE\\LocalServer\\Config\\Lis tenPort}"); if(LocalServerPort ! = 0) { return true; } return false; } IsLocalServerActive = CheckLocalServer(); // --> Si le serveur 228 est détecté comme inactif à l'étape E304, le programme peut inviter l'utilisateur à lancer le serveur local pair-à-pair 228 en lançant une fenêtre de dialogue à l'aide d'une fonction de l'activeX. Si l'utilisateur accepte la proposition, une fonction de l'activeX est appelée pour lancer le serveur local à l'étape E307. A l'étape E311, on procède à la suite de l'interprétation de la page HTML 25. En référence à la figure 4, à chaque fois que la page HTML 25 est analysée par une application telle qu'un navigateur Internet ou un lecteur de courrier électronique (227,237), une fonction javascript embarquée dans la page est appelée pour chaque référence à un contenu numérique afin de retourner l'adresse URL à utiliser pour accéder audit contenu numérique. L'appel à cette fonction dans la page HTML peut prendre la forme suivante : GetRessourceAddress('abcde23404-3143492ef-23232', 'blue~mountain.jpg'); La balise (de l'anglais tag ) marque le début d'un code à exécuter dans la page HTML où la valeur ### mentionne la nature du langage utilisé (JavaScript ou VBScript par exemple). La balise indique la fin du code à exécuter. GetRessourceAddress correspond ici au nom de la fonction JavaScript à appeler. Cette fonction doit être préalablement définie, soit dans un fichier externe dont le nom se termine avec l'extension .js et lui-même référencé dans la page HTML, soit directement en début de page HTML (c'est- à-dire dans l'entête délimité par les balises et dans une section de code JavaScript délimitée par les balises et Dans le premier cas, si le nom du serveur hébergeant le script est www.server.com et que le fichier contenant la définition de la fonction s'appelle mp.js et se trouve dans le répertoire script sur le serveur, la commande incluant le fichier mp.js dans la page HTML est : La figure 4 décrit le comportement de la fonction javascript GetRessourceAddress chargée de retourner l'adresse URL. Le code correspondant en JavaScript peut être le suivant : function GetRessourceAddress(resID, title) { if(isLocalServerActif == false) { document.write(" "); document.write(title); document.write(" "); } Le mot clé function indique la création d'une nouvelle fonction ayant ici pour nom GetRessourceAddress et ayant pour paramètres deux variables resID et title. JavaScript possède une commande appelée document. write (#) permettant d'afficher des informations en passant cette information notée ici dièse au programme en train d'interpréter la page HTML. L'information passée doit donc être au format HTML pour être compréhensible par l'interpréteur. Les mots isLocalServerActif et localServerHTTPPort représente des variables JavaScript préalablement initialisées (figure 3). La première variable indique un serveur local pair-à-pair est actuellement installé et actif sur la machine et la seconde variable indique le numéro de port sur lequel le serveur local pair-à-pair est en attente. Selon l'invention l'algorithme est donc le suivant : La fonction JavaScript ici notée GetRessourceAddress avec au moins en paramètres l'identifiant unique de la ressource notée resID est appelée (étape E401) pour chacune des références aux ressources dans la page HTML 25. A l'étape E402, la fonction vérifie si un serveur local pair-à-pair a été détecté par l'algorithme de la figure 3 en vérifiant la valeur d'une variable notée ici isLocalServerActif. A l'étape E403, si la variable indique qu'il n'y a pas de serveur local pair-à-pair actuellement actif (la valeur de la variable vaut false), alors la fonction retourne à l'étape E404 une URL permettant d'accéder à la ressource via une adresse prédéfinie correspondant à un serveur de type proxy/passerelle 24 dont le nom pour l'exemple serait www.server.com. A partir du code de la fonction JavaScript et de l'exemple d'appel décrit précédemment, le code HTML retourné par la fonction est le suivant : 'blue~mountain.jpg' Ce code représente un lien hypertexte ayant pour nom blue~mountain.jpg et pointant vers l'adresse http://www.server.com/abcde23404-3143492ef-23232. A l'étape E403, si la variable indique qu'il existe un serveur local pair-à-pair actif sur la machine (la valeur de la variable vaut true), alors la fonction retourne à l'étape E405 une URL permettant d'accéder à la ressource via le serveur local qui joue ici le rôle de proxy (figure 5). Le code HTML retourné par la fonction serait alors : 'blue~mountain.jpg' en supposant que la variable localServerHTTPPort vaut 90. Dans une autre variante, plutôt que d'appeler la fonction javascript GetRessourceAddress pour chacune des références à un contenu numérique, ces références peuvent être écrites sous la forme d'une URL relative. Un exemple de code HTML pour une référence peut être alors de la forme suivante : 'blue~mountain.jpg' L'appel répétitif à la fonction javascript GetRessourceAddress pour chacune des références à un contenu numérique est alors avantageusement remplacé par un appel unique à une routine javascript chargée de définir une balise dans l'entête de la page HTML 25. Cette balise définit une URL absolue utilisée comme URL de base pour résoudre les URLs relatives. La fonction javascript retourne une balise pointant sur un serveur de type proxy/passerelle 24 s'il n'y a pas de serveur local pair-à-pair actif sur la machine (la valeur de la variable isLocalServerActif vaut false). Le code HTML retourné par la fonction est alors : La fonction javascript retourne une balise pointant sur un serveur local 228 s'il existe un serveur local pair-à-pair actif sur la machine (la valeur de la variable isLocalServerActif vaut true). Le code HTML retourné par la fonction est alors : en supposant que la variable localServerHTTPPort vaut 90. En référence à la figure 5, on a décrit le comportement des serveurs locaux 228 et 218. Selon l'invention quand le serveur local pair-à-pair reçoit une requête pour un contenu numérique R (E511), il détermine à l'étape E512 si la requête provient d'une application distante (présente sur une autre machine du réseau de communication) ou si la requête provient d'une application locale (s'exécutant sur la même machine que le serveur). Il détermine cette nformation en examinant l'adresse IP du demandeur et en la comparant à ;hacune de ses propres adresses IP. Si deux adresses sont identiques ou si 'adresse du demandeur est 127. 0.0.1 (adresse loopback), c'est que le jemandeur est local, autrement il s'agit d'un demandeur distant. Si le demandeur est local, le serveur passe à l'étape E513 et vérifie si la donnée recherchée R n'est pas présente localement sur le disque. 3i la donnée est présente localement, alors elle est envoyée au demandeur étape E517). Si la donnée n'est pas présente localement alors le serveur effectue une recherche de la ressource sur le réseau pair-à-pair suivant des echniques connus de l'homme du métier (étape E514). A l'étape E515, si la tonnée est trouvée sur le réseau alors le serveur télécharge la donnée R à 'étape E516, la sauvegarde localement dans son cache sur le disque et la "etourne au demandeur à l'étape E517. Dans le cas contraire, le serveur ^etourne une erreur à l'étape E518 au demandeur pour lui signaler que la tonnée n'est pas disponible. Si le demandeur est distant, le serveur vérifie à l'étape E519 si la 'essource est disponible localement sur son disque. Si la donnée est disponible, elle est retournée au demandeur à 'étape E520. Dans le cas contraire, il vérifie à l'étape E521 si la requête est une 'equête WEB provenant par exemple d'un navigateur Internet (sous la forme j'une URL http://y/x où [x] est le chemin d'accès à la ressource sur la machine dentifiée par [y], ou encore sous la forme d'un en-tête particulier dans la ^equête) ou s'il s'agit d'une requête suivant un protocole propriétaire : S'il s'agit d'une requête WEB, le serveur procède alors à une ^echerche de la donnée sur le réseau pair-à-pair à l'étape E522. On ^etrouve ici le comportement de proxy/passerelle de la machine 24. A l'étape E523, si la ressource est localisée dans le réseau pair- à-pair le serveur ne télécharge pas la ressource mais au contraire redirige à 'étape E524 le demandeur vers la machine ayant la ressource recherchée à l'aide d'un ordre de redirection ( forward en anglais) dont une forme simple avec le protocole HTTP serait : HTTP/1.1 302 See other URI Location : http://nnn/zzz Le premier mot clé http/1.1 permet d'indiquer le type et la version du protocole. 302 est une valeur d'erreur particulière indiquant que la ressource n'est pas disponible temporairement sur le serveur. Un commentaire pouvant être affiché suit ce code d'erreur. Location : est le deuxième mot clé indiquant au navigateur Internet de se rediriger sur un autre URI. [nnn] est l'adresse de la machine à contacter pour obtenir la ressource et [zzz] est le chemin d'accès à la ressource sur la machine [nnn]. A l'étape E523, si la ressource n'est pas localisée dans le réseau pair-à-pair , le serveur redirige à l'étape E525 le demandeur vers une machine prédéterminée à l'aide d'un ordre de redirection similaire au précédent. Cette machine prédéterminée est chargée de traiter les cas où la ressource demandée n'est pas disponible en retournant par exemple une réponse prédéterminée invitant l'utilisateur à renouveler sa requête ultérieurement par exemple. Si à l'étape E521, il ne s'agit pas d'une requête WEB provenant d'un navigateur Internet mais d'une requête provenant d'une application pair-à-pair dédiée alors le serveur retourne une erreur au demandeur. Par exemple la page HTML peut avoir la teneur suivante : If detectableWithVB Then detectActiveXControl = IsObject(CreateObject(activeXControlName)) End If End Function rem --> '); document.writeln(" "); // --> function GetRessourceAddress (imageID, title) { document.writeln(""); document.writeln("Process the image ID..."); if(isLocalServerActif == false) { document.write(" "); } CheckServer (); // --> No JavaScript You see this text if JavaScript is disabled or unimplemented. GetRessourceAddress ('abcde23404-3143492ef-23232', 'blue~mountain.jpg'); GetRessourceAddress ('fffffeeeaa-bbe478999-aaaaa', 'red~mountain.jpg'); Parmi les nombreux avantages conférés par la présente invention, il est possible de mettre en exergue qu'il n'est pas nécessaire d'adapter le contenu de la notification selon les capacités des destinataires, c'est-à-dire selon qu'il possède ou non l'application locale P2P dédiée. De plus, l'accès local ou distant est totalement transparent pour l'utilisateur. De même, il n'est pas nécessaire de modifier la configuration Internet de l'utilisateur (en l'occurrence les adresses du dispositif serveur mandataire ou proxy). Enfin, les dispositifs clients possédant l'application P2P n'ont pas l'obligation de garder leur serveur local actif pour pouvoir afficher le contenu d'une notification reçue par courrier électronique, l'affichage de la notification s'adaptant automatiquement en fonction de la présence/absence d'un serveur local. REVENDICATIONS 1. Procédé d'accès à au moins un document numérique disponible dans un réseau de communication (13) reliant des dispositifs clients (21, 22,23) entre eux, ledit procédé d'accès étant mis en oeuvre au sein d'un dispositif client destinataire (22,23) ledit procédé comprenant les étapes suivantes : -i) recevoir une notification (25) indiquant la présence d'au moins un document numérique disponible sur le réseau (13), ladite notification (25) comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, -ii) exécuter la ou les commandes afin de détecter la présence et l'activation de l'application locale, et -iii) en cas d'application locale présente et active, accéder au document numérique à partir d'un serveur local (228) tandis qu'en cas d'absence ou d'inactivité de l'application locale, accéder au document à partir de l'adresse d'un serveur distant (24). 2. Procédé selon la revendication 1, caractérisé en ce que la notification (25) comprend, en outre, au moins une page en langage de balisage contenant au moins un identifiant désignant le document numérique, et une adresse distante désignant un serveur distant (24). 3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre, à l'issue de l'étape ii) et avant l'étape iii), l'étape iia) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder à l'activation de l'application locale à la suite d'une autorisation de l'utilisateur du dispositif client destinataire accordée en réponse à une commande exécutable choisie. 4 Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre, à l'issue de l'étape ii) et avant l'étape iii), l'étape iib) dans laquelle, en cas d'application locale présente et inactive, il est prévu de procéder automatiquement à l'activation de l'application locale conformément à une commande exécutable choisie. 5 Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre, après l'étape iii), l'étape iv) dans laquelle, en cas d'application locale présente et active, il est prévu de vérifier la présence du document dans un serveur local (228), et en cas de vérification négative de rechercher ledit document dans le réseau (13), de le télécharger en cas de recherche positive, et de le sauvegarder localement avant de le servir. 6. Procédé selon la revendication 2, caractérisé en ce que lors d'une application locale présente et active, il est prévu d'adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse d'un serveur local (228). 7. Procédé selon la revendication 6, caractérisé en ce que l'adaptation de la page (25) comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur local (228). 8. Procédé selon la revendication 2, caractérisé en ce que lors d'une application locale absente ou inactive, il est prévu d'adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse d'un serveur distant (24). 9. Procédé selon la revendication 8, caractérisé en ce que 'adaptation de la page (25) comprend le positionnement d'une variable de pointage en langage de balisage sur l'adresse d'un serveur distant (24). 10 Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que le réseau de communication (13) est de type pair à pair, centralisé, décentralisé ou hybride. 11 Procédé selon la revendication 2, caractérisé en ce que le langage de balisage de la page (25) est de type HTML ou analogue. 12. Procédé selon la revendication 11, caractérisé en ce que la ou les commandes exécutables sont de type programme Script tel que java script ou VBscript, la ou les commandes exécutables étant embarquées dans la page ainsi notifiée, et ladite page étant interprétée lors de l'étape ii). 13. Procédé selon la revendication 12, caractérisé en ce que l'adresse locale désignant un serveur local (228) est déterminée par le programme Script apte à récupérer les paramètres de configuration dudit serveur local. 14. Procédé selon la revendication 12, caractérisé en ce que la ou les commandes incluses dans la page (25) en langage de balisage font appel à un programme local du type activeX ou analogue, apte à déterminer la présence et l'activation du serveur local, ainsi qu'à récupérer les paramètres de configuration dudit serveur local. 15. Procédé selon la revendication 13 ou la revendication 14, caractérisé en ce que la ou les commandes comprennent en outre une fonction apte à pointer une adresse locale (228) ou distante (24) permettant d'accéder au document. 16. Procédé selon la revendication 12, caractérisé en ce que la page (25) est notifiée en attachement avec un courrier électronique. 17. Procédé selon la revendication 2, caractérisé en ce que la page (25) est téléchargée sur un serveur distant choisi (24), et en ce qu'une référence à cette page est envoyée à tout destinataire à notifier. 18. Procédé selon la revendication 16 et la revendication 17, caractérisé en ce que la référence de la page (25) est de type URL, incluse dans un courrier électronique. 19. Procédé de partage d'un document numérique dans un réseau de communication (13) reliant des dispositifs clients (21,22, 23) entre eux, ledit procédé étant mis en #uvre au sein d'un dispositif client émetteur (21), ledit procédé comprenant l'étape suivante : émettre à destination d'au moins un dispositif client destinataire (22,23) une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, et en cas d'application locale présente et active, à accéder au document à partir de l'adresse d'un serveur local (228) sinon à accéder au document à partir de l'adresse d'un serveur distant (24). 20. Procédé de partage selon la revendication 19, caractérisé en ce que la notification comprend, en outre, une page (25) en langage de balisage contenant au moins un identifiant désignant le document numérique et une adresse distante désignant un serveur distant (24). 21. Dispositif d'accès à au moins un document numérique disponible dans un réseau de communication (13) reliant des dispositifs clients entre eux (21,22, 23), ledit dispositif d'accès étant intégré au sein d'un dispositif client destinataire (22,23), ledit dispositif d'accès étant caractérisé en ce qu'il comprend : des moyens de réception (227), aptes à recevoir une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale susceptible de traiter le document numérique, - des moyens d'exécution (227) aptes à exécuter la commande afin de détecter la présence et l'activation de l'application locale, et - des moyens de traitement (227,228) aptes, en cas d'application locale présente et active, à accéder au document numérique à partir d'un serveur local, tandis qu'en cas d'absence ou d'inactivité de l'application locale, à accéder au document à partir d'un serveur distant. 22. Dispositif selon la revendication 21, dans lequel la notification comprend, en outre, au moins une page (25) en langage de balisage contenant au moins un identifiant désignant le document numérique et une adresse distante désignant un serveur distant (24). 23. Dispositif selon la revendication 22, caractérisé en ce que lors d'application locale présente et active, les moyens de traitement (227,228) sont aptes à adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse du serveur local (228). 24. Dispositif selon la revendication 22, caractérisé en ce que les moyens de traitement (227,228) sont aptes à positionner une variable de pointage en langage de balisage sur l'adresse du serveur local (228). 25. Dispositif selon les revendications 22 à 24, caractérisé en ce qu'en cas d'application locale (229) absente ou inactive, les moyens de traitement (227,228) sont aptes à adapter localement la page (25) en langage de balisage de manière à accéder au document à partir de l'adresse du serveur distant (24). 26. Dispositif selon la revendication 25, caractérisé en ce que les moyens de traitement (227,228) sont aptes à positionner une variable de pointage en langage de balisage sur l'adresse du serveur distant (24). 27. Dispositif selon l'une quelconque des revendications 21 à 26, caractérisé en ce que le réseau de communication (13) est de type pair à pair, centralisé, décentralisé ou hybride. 28. Dispositif selon la revendication 22, caractérisé en ce que la page (25) est en langage de balisage de type HTML. 29. Dispositif selon la revendication 28, caractérisé en ce que la ou les commandes sont de type programme script tel que javascript ou VBscript, la ou lesdites commandes étant embarquées dans la page (25) ainsi notifiée et ladite page étant interprétée. 30. Dispositif selon la revendication 29, caractérisé en ce que la commande comprend en outre une fonction apte à pointer une adresse locale (228) ou distante (24) permettant d'accéder au document. 31. Dispositif selon la revendication 22, caractérisé en ce que la page (25) est notifiée en attachement avec un courrier électronique, le dispositif étant en outre équipé d'un logiciel de traitement de courrier électronique (227). 32 Dispositif de partage d'un document numérique dans un réseau de communication (13) reliant des dispositifs clients (21,22, 23) entre eux, ledit dispositif de partage étant intégré au sein d'un dispositif client émetteur (21), caractérisé en ce qu'il comprend des moyens d'émission aptes à émettre à destination d'au moins un dispositif client destinataire (22,23) une notification indiquant la présence d'au moins un document numérique disponible sur le réseau, ladite notification comprenant au moins une commande exécutable apte à détecter si le dispositif client destinataire comprend une application locale (229) susceptible de traiter le document numérique, et en cas d'application locale présente et active, à accéder au document à partir de l'adresse d'un serveur local sinon à accéder au document à partir de l'adresse d'un serveur distant. 33. Dispositif de partage selon la revendication 32, caractérisé en ce que la notification comprend, en outre, une page (25) en langage de balisage contenant au moins un identifiant désignant le document numérique et une adresse distante désignant un serveur distant (24). 34. Support d'informations lisible par un système informatique, éventuellement amovible, totalement ou partiellement, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en #uvre du procédé selon l'une quelconque des revendications 1 à 18, ou 20 à 21, lorsque ce programme est chargé et exécuté par un système informatique. 35. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en #uvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 18, ou 20 à 21, lorsque le programme est chargé et exécuté par un système informatique.