FR 2844659 A1 20040319 FR 0211462 A 20020916 i Procédé de limitation de transfert de fichiers informatiques, dispositifs et programmes d'ordinateurs correspondants La présente invention se rapporte au domaine des transferts de fichiers sur des réseaux de communication. Plus précisément, l'invention concerne la limitation de transferts de fichiers informatiques en vue de restreindre voire d'empêcher l'aboutissement de requêtes de transferts de fichiers en particulier non autorisés et/ou illicites. En effet, par le biais de réseau internet et notamment P2P (ou " peerto10 peer " en anglais et " de pair à pair " en français), de nombreux utilisateurs téléchargent des fichiers de manière illicite ou non désirée par l'auteur de ces fichiers. Il s'agit notamment de fichiers audiovisuels (par exemple de type MP3) ou plus généralement de fichiers contenant des informations protégées par le droit 15 d'auteur et qui ne peuvent donc être copiés sans autorisation ou rétribution (par exemple sous la forme d'un paiement de licence). Il peut s'agir également de données confidentielles issues, par exemple, d'une entreprise ou encore de données dont l'échange est contraire à l'ordre public et/ou aux bonnes moeurs (par exemple données liées au terrorisme, à la pédophilie,...). Dans un réseau P2P, un noeud (ou " peer ") peut aussi bien être serveur que consommateur de ressources. Il n'y a alors plus de distinction entre les dispositifs (par exemple de type ordinateurs) qui publient des données (par exemple des fichiers musicaux au format MP3) et ceux qui les consomment. Lorsqu'un noeud demande des données sur un réseau P2P, il ne connaît pas la localisation de ces 25 données et diffuse simplement une requête sur ce réseau pour qu'un noeud tiers possédant cette ressource puisse la lui fournir. On distingue principalement deux types de réseaux P2P: - d'une part, les réseaux P2P fonctionnant avec des serveurs centralisés selon une architecture de type client/serveurs (par exemple, les réseaux FastTrack, iMesh, AudioGalaxy, MFTP et OpenNap (marques déposées)); et - d'autre part, les réseaux P2P faisant intervenir chaque membre du réseau pour agir en tant que " servent " (terme technique 5 issu de la combinaison des termes " serveur " et " client "), et qui ne possèdent pas de structure principale (par exemple, les réseaux Gnutella et DirectConnect (marques déposées)). Un réseau P2P possède plusieurs fonctionnalités permettant une large diffusion des données disponibles et un transfert fiable de requêtes et de leurs 10 réponses entre les noeuds du réseau, notamment: - une publication des ressources: pour partager des données, un noeud publie des informations sur ces données qu'il rend consultable par les autres noeuds selon des standards, permettant à ces derniers la recherche des données partagées grâce à une 15 requête de recherche; - une localisation des données: des bases de données mises à jour en temps réel et présentes sur le réseau permettent de localiser les données requises sur le réseau P2P; et - un appel des données localisées permettant leur téléchargement 20 d'un noeud possédant les données requises vers un noeud requérant. A titre d'exemple illustratif, dans une architecture décentralisée de réseau P2P, un ordinateur requérant émet une requête de fichier MP3 vers les noeuds auxquels il est connecté. Ces derniers vérifient s'ils peuvent répondre à la requête 25 et, dans l'affirmative, transmettent la réponse au requérant, puis, généralement répercutent la requête vers les autres noeuds auxquels ils sont eux-mêmes connectés et qui effectuent alors un traitement similaire (une requête n'est notamment pas répercutées si un niveau de saut maximum de noeud à noeud est atteint lorsque le protocole P2P prévoit un tel niveau ou si un algorithme de 30 redondance évite la multiplication des requête ou, encore, si un noeud est configuré en noeud terminal qui ne répercute aucune requête). La requête est ainsi diffusée à travers tout ou partie du réseau P2P et de nombreuses réponses localisant le fichier MP3 requis peuvent ainsi parvenir au noeud requérant. Ce dernier sélectionne alors la ou les réponses les plus pertinentes selon des critères 5 prédéterminés (vitesse de réponse, qualité présumée du fichier...) et demande le fichier requis en fonction des réponses sélectionnés jusqu'au téléchargement correct du fichier ou jusqu'à un abandon de la procédure de requête. Selon un deuxième exemple, dans une architecture centralisée de réseau P2P, un ordinateur requérant émet une requête de fichier MP3 vers un serveur 10 auquel il est connecté. Dans une telle architecture, chaque noeud client est connecté à un serveur et chaque serveur possède une base de données mise à jour en temps réel et listant les fichiers MP3 des clients auxquels il est relié. Chaque serveur vérifie s'il peut répondre à une requête reçue et, dans l'affirmative, transmet la réponse au requérant, puis généralement répercute la requête vers les 15 autres serveurs auxquels il est lui-même connecté. La requête est ainsi diffusée à travers tout ou partie du réseau P2P. Le requérant sélectionne alors les réponses reçues et invoque le fichier requis selon une méthode similaire à celle mise en oeuvre dans une architecture décentralisée. On connaît dans l'état de la technique différents types de protection des 20 données visant à en limiter la diffusion de manière illicite et/ou non autorisée, notamment: - le tatouage de fichiers; - la pollution; - le DRM (de l'anglais " Digital Rights Management " ou 25 " Gestion des Droits Numériques " en français); et - l'espionnage. Un système de tatouage numérique des fichiers est un outil visant à permettre le contrôle de la diffusion des fichiers sur des réseaux P2P. Dans le cadre de normes spécifiques, cette solution (développée, par exemple, par les 30 sociétés Thomson Multimédia et Yacast (marques déposées)) permettant le suivi (ou la " traçabilité ") des fichiers est prévue pour s'intégrer dans les appareils de musique et dans les logiciels de lecture audio et/ou vidéo. Le tatouage repose sur l'association de chaque fichier et d'une signature stockée dans une base de données. Dans le cas de fichiers musicaux, des appareils de lectures peuvent reconnaître la signature sonore. Cette technique présente l'inconvénient de n'être efficace qu'avec l'accord de l'internaute et la collaboration des fabricants de matériel de lecture (lecteurs MP3, ordinateurs,...). Il faut en effet qu'une vérification du tatouage soit intégrée dans le matériel de lecture pour empêcher les téléchargements illicites ou non 10 autorisés et/ou leur exploitation. Une autre solution connue dans l'art antérieur consiste à polluer le réseau par des répliques des fichiers requis, qui sont de mauvaise qualité. D'un point de vue éthique, cette technique est mal acceptée notamment par l'industrie du disque et porte préjudice à la notoriété des artistes et des éditeurs. De plus, des logiciels 15 P2P permettent de ne pas prendre en compte des fichiers pollués en utilisant la certification de fichiers (après réception d'un fichier téléchargé, un client transmet une signature vers une base de certification qui indique au client si cette signature est correcte ou non). Le DRM est un environnement technologique développé par la société 20 Intertrust (marque déposée) qui permet de diffuser en toute sécurité des contenus numériques sur le réseau Internet. Il comprend deux éléments principaux: - un mécanisme de cryptage qui prévient la modification des fichiers; et - un contrôle d'utilisation qui limite l'emploi et la distribution du 25 fichier concerné. Ainsi, le DRM permet aux détenteurs de droits d'auteur de contrôler la circulation de leurs oeuvres. Cependant, le DRM présente l'inconvénient de ne pas empêcher la transmission de fichiers issus de supports non sécurisés (par exemple des disques compacts non sécurisés qui permettent le transfert des 30 fichiers musicaux au format MP3). La technique d'espionnage consiste à s'immiscer dans les réseaux P2P afin de les espionner. Un avertissement est émis vers des consommateurs de fichiers pirates, qui doivent alors effacer les titres pour lesquels ils ne possèdent pas les droits. Cette solution juridiquement valable aux Etats-Unis ne l'est pas partout 5 ailleurs. En outre, elle n'est applicable qu'à certains utilisateurs et ne peut être mise en oeuvre dans des réseaux P2P décentralisés comme Gnutella (marque déposée). L'invention selon ses différents aspects a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention est de fournir un système, un procédé et/ou des dispositifs fiables et efficaces de limitations de transfert de fichiers illicites et/ou non autorisés sur un réseau P2P. Un autre objectif de l'invention est d'empêcher ou de limiter le transfert illicite et/ou non autorisé de fichiers informatiques sans adaptation et/ou 15 modification particulière d'un noeud susceptible de requérir de tels fichiers sur un réseau P2P. L'invention a également pour objectif une mise en oeuvre simple d'une limitation de transferts illicites et/ou non autorisés de fichiers dans un réseau P2P. Un objectif complémentaire de l'invention est de fournir un procédé de 20 limitation de transfert illicite et/ou non autorisé de fichiers, qui est compatible avec les réseaux P2P existants. Un objectif de l'invention est aussi de permettre une limitation de transfert ciblée vers des fichiers spécifiques. Dans ce but, l'invention propose un procédé de limitation de transfert de 25 fichiers informatiques dans un réseau de communication pair à pair (" peer to peer "), au moins un premier noeud du réseau étant susceptible de diffuser vers au moins un second noeud du réseau au moins une requête de recherche d'un fichier à transférer, remarquable en ce qu'au moins un des seconds noeuds est adapté pour transmettre au moins une réponse dite de leurre, comprenant une information 30 représentative d'un emplacement fictif du fichier à transférer. Un réseau pair à pair (P2P) est ici un réseau qui permet des téléchargements directement entre utilisateurs, l'adresse d'un fichier à télécharger n'étant généralement pas communiquée directement par un noeud contenant le fichier mais par un serveur (le flux de recherche étant alors géré par le réseau 5 contrairement à un transfert direct de type FTP dans un réseau quelconque); dans un réseau P2P, un utilisateur ne connaît généralement pas l'emplacement d'un fichier qu'il souhaite télécharger: c'est le réseau qui communique à cet utilisateur un ou plusieurs emplacements possibles. Selon l'invention, le ou les seconds noeuds qui peuvent être notamment de 10 type clients ou serveurs dans une architecture centralisée ou semicentralisée de réseau P2P ou de type servents dans une architecture décentralisée sont adaptés à répondre aux requêtes de recherche de fichier avec une ou plusieurs réponses de leurre: - directement (le ou les seconds noeuds sont, par exemple, 15 configurés pour transmettre des réponses de leurre à au moins certaines requêtes de recherche de fichier); et/ou indirectement (le ou les seconds noeuds sont adaptés à construire des messages de leurre en réponse à au moins certaines requêtes de recherche de fichier sans être configuré 20 pour cela mais définissent les réponses en fonction des bases de données qui, par exemple, contiennent des données communiquées par des équipements tiers, ces données comprenant des emplacements de leurre). L'invention permet donc de limiter et/ou d'empêcher le téléchargement de 25 certains fichiers en transmettant des adresses de leurre. Elle est ainsi plus efficace que les solutions de l'art antérieur et notamment que la pollution pour laquelle il existe une parade (la certification). Ici, la certification (fonctionnant sur base de la signature du fichier et non d'un chemin d'accès) ne peut être mise en oeuvre par un premier noeud susceptible de télécharger un fichier puisque le client recevant des réponses de leurre, le téléchargement même d'un fichier correspondant a peu de chance d'être effectué. Selon une caractéristique particulière, le procédé est remarquable en ce que le ou les seconds noeuds sont adaptés pour transmettre au moins vingt réponses distinctes parmi les réponses de leurre. Selon une caractéristique particulière, le procédé est remarquable en ce que le ou les seconds noeuds sont adaptés pour transmettre au moins cent réponses distinctes parmi les réponses de leurre. Ainsi, le premier noeud reçoit, avec une forte probabilité, un nombre 10 beaucoup plus grand de réponses de leurre que de réponses correctes. Suite à la réception des réponses, une requête de transfert du fichier a alors de forte chance d'être ciblée vers un emplacement fictif du fichier et donc de ne pas aboutir. Le ou les seconds noeuds pourront transmettre, par exemple, cent réponses de leurre, s'il est probable que le premier noeud est susceptible de recevoir cinq 15 réponses correctes à sa requête de recherche de fichier. Le nombre minimal de réponses pourra être étalonné à l'initialisation et/ou sur événement et/ou en temps réel en fonction de différents critères et notamment de l'état du réseau, du fichier requis, du type de fichier requis... Selon une caractéristique particulière, le procédé est remarquable en ce 20 que, dans au moins un des seconds noeuds, on met en oeuvre les étapes suivantes: - réception de la requête de recherche; et - transmission vers le premier noeud d'une réponse de leurre, comprenant une information représentative d'un emplacement fictif du fichier à transférer, si au moins un premier critère prédéterminé de 25 limitation de transfert est vérifié. Selon une caractéristique particulière, le procédé est remarquable en ce qu'un des critères prédéterminés est l'appartenance d'un identificateur du fichier à transférer à une liste prédéterminée d'au moins un fichier non autorisé pour un téléchargement. Selon une caractéristique particulière, le procédé est remarquable en ce que le second noeud met en oeuvre une étape de vérification que la requête répond au ou aux premiers critères prédéterminés. Selon une caractéristique particulière, le procédé est remarquable en ce que 5 le second noeud retransmet la requête de recherche à des noeuds auxquels il est relié si les premiers critères ne sont pas vérifiés. Ainsi, la vérification permet non seulement de déterminer si une ou plusieurs réponses de leurre doivent être émises suite à la réception de la requête de fichier à transférer mais également si la requête doit être relayée ou non. De cette manière, si la requête ne correspond pas à un fichier non autorisé, le procédé de limitation ne perturbe pas le réseau P2P et, au contraire, participe à son bon fonctionnement. Si en revanche, la requête correspond à un fichier non autorisé, non seulement le premier noeud reçoit des réponses de leurre, mais encore la requête 15 n'est pas diffusée par le ou les seconds noeuds mettant en oeuvre de façon active la limitation. Selon une caractéristique particulière, le procédé est remarquable en ce que le second noeud met en oeuvre une étape de génération de l'information représentative d'un emplacement fictif du fichier à transférer après la réception de 20 la requête de recherche. Ainsi, les réponses de leurre sont préparées à la volée, ce qui permet une économie des ressources (notamment de la mémoire et du temps de traitement). Selon une caractéristique particulière, le procédé est remarquable en ce que le second noeud met en oeuvre une étape de génération d'une information 25 représentative d'un emplacement fictif pour chacun des fichiers appartenant à la liste prédéterminée d'au moins un fichier non autorisé pour un téléchargement avant la réception de la requête de recherche. Ainsi, les réponses de leurre sont préparées à l'avance, ce qui permet une transmission rapide de la ou des réponses de leurre et donc une plus grande efficacité du procédé, les premières réponses reçues par le premier noeud étant susceptibles d'être sélectionnées en priorité. Selon une caractéristique particulière, le procédé est remarquable en ce que le réseau possède au moins en partie une architecture client-serveur et en ce que le second noeud est un serveur du réseau. Selon une caractéristique particulière, le procédé est remarquable en ce qu'au moins un troisième noeud transmet au second noeud au moins une liste d'emplacements de fichiers fictifs et en ce que le second noeud met à jour une liste de localisation de fichiers susceptibles d'être téléchargés en fonction de la liste 10 d'emplacements de fichiers fictifs. Ainsi, la mise en oeuvre de l'invention est particulièrement simple: - le second noeud met en oeuvre indirectement l'invention sans configuration particulière; et - le ou les troisièmes noeuds étant par exemple des noeuds dédiés 15 à la limitation de transfert de fichiers illicites ou non autorisés, étant simplement adaptés à la transmission (périodique, sur événement, aléatoire...) d'une ou de plusieurs listes d'emplacement de fichiers fictifs correspondant à des fichiers à protéger. Selon une caractéristique particulière, le procédé est remarquable en ce que le réseau possède une architecture décentralisée. Selon une caractéristique particulière, le procédé est remarquable en ce que les fichiers sont des fichiers de type audiovisuel, contenant des informations représentatives de son et/ou d'images. Selon une caractéristique particulière, le procédé est remarquable en ce que les fichiers sont des fichiers de type contenant du texte et/ou un programme d'ordinateur. Ainsi, l'invention est particulièrement bien adaptée à la limitation du transfert de fichiers: - de son (par exemple de musique et/ou fichiers MP3, WAV ou OGG); - d'images animées (par exemple de films et/ou fichiers AVI, DIVX ou MPG); - d'images fixes (par exemple photographies, dessins et/ou fichiers JPG, GIF, PNG); - de texte (par exemple au format TXT, DOC, HTML et/ou PDF); et/ou - de programmes d'ordinateurs (par exemple logiciels, jeux 10 vidéos et/ou fichiers EXE, ZIP, RAR et/ou HQX). En effet, ces fichiers sont généralement protégés par le droit d'auteur et/ou confidentiel (notamment pour une entreprise et/ou un état). Ces fichiers peuvent contenir également des données par nature illégale ou contraires aux bonnes moeurs ou à l'ordre public (par exemple, données liées au 15 terrorisme ou à la pédophilie, données censurées...). L'invention concerne également un serveur adapté à une limitation de transfert de fichiers informatiques dans un réseau de communication pair à pair (" peer to peer "), au moins un premier noeud du réseau étant susceptible de diffuser vers le serveur au moins une requête de recherche d'un fichier à 20 transférer, le serveur étant remarquable en ce qu'il comprend des moyens de transmission d'au moins une réponse dite de leurre, comprenant une information représentative d'un emplacement fictif du fichier à transférer. Le serveur comprend préférentiellement: - des moyens de réception de requêtes de recherche; et 25 - des moyens de transmission vers le premier noeud d'au moins une réponse dite de leurre, comprenant une information représentative d'un emplacement fictif du fichier à transférer, si au moins un premier critère prédéterminé de limitation de transfert est vérifié. L'invention concerne aussi un noeud de type client, adapté à une limitation de transfert de fichiers informatiques dans un réseau de communication pair à pair (" peer to peer ") comprenant des clients et des serveurs, au moins un premier noeud du réseau étant susceptible de diffuser vers au moins un second noeud 5 duréseau au moins une requête de recherche d'un fichier à transférer, le noeud de type client étant remarquable en ce qu'il comprend: - des moyens de génération d'au moins une information dite de leurre, représentative d'un emplacement fictif de fichiers prédéterminés susceptibles d'être requis pour un transfert dans 10 le réseau; et - des moyens de transmission de la ou des informations de leurre vers au moins un des seconds noeuds, de sorte à ce que le ou les seconds noeuds puissent prendre en compte la ou les informations de leurre pour répondre à la ou aux requêtes de 15 recherche d'un fichier à transférer. En outre, l'invention concerne un produit programme d'ordinateur comprenant des éléments de programme, enregistrés sur un support lisible par au moins un microprocesseur, remarquable en ce que les éléments de programme contrôlent le ou les microprocesseurs pour que, dans un réseau de communication 20 pair à pair (" peer to peer "), au moins un premier noeud du réseau étant susceptible de diffuser vers au moins un second noeud du réseau au moins une requête de recherche d'un fichier à transférer, ils effectuent une étape de transmission d'au moins une réponse dite de leurre, comprenant une information représentative d'un emplacement fictif du fichier à transférer. De plus, l'invention concerne un produit programme d'ordinateur, remarquable en ce qu'il comprend des séquences d'instructions adaptées à la mise en oeuvre d'un procédé de limitation de transfert de fichiers tel que précédemment décrit selon l'invention, lorsque le programme est exécuté sur un ordinateur. Les avantages des serveurs, noeuds et programmes d'ordinateurs sont les mêmes que ceux du procédé de limitation de transfert de fichiers informatiques, ils ne sont pas détaillés plus amplement. D'autres caractéristiques et avantages de l'invention apparaîtront plus 5 clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels: - La figure 1 présente une architecture de réseau P2P semi-centralisée comportant des noeuds " serveurs " conformes à l'invention selon un 10 mode particulier de réalisation; - La figure 2 illustre une architecture de réseau P2P décentralisée conforme à l'invention selon un autre mode particulier de réalisation; - La figure 3 décrit une architecture de réseau de type semi-centralisée comportant des noeuds " clients " conformes à l'invention selon un 15 mode particulier de réalisation; - La figure 4 présente une architecture de dispositif de type serveur ou servent présent dans l'architecture illustrée respectivement en regard des figures 1 ou 2; - La figure 5 illustre un protocole entre différents éléments du réseau 20 P2P de la figure 1; - La figure 6 illustre un protocole de communication entre différents éléments illustrés en regard de la figure 2; - La figure 7 décrit un organigramme de procédé mis en oeuvre dans un serveur tel qu'illustré en regard de la figure 1; La figure 8 illustre un protocole de communication entre différents éléments du réseau illustré en regard de la figure 3; et - La figure 9 illustre un organigramme d'algorithmes mis en oeuvre dans un noeud décrit en regard de la figure 3. Le principe général de l'invention repose sur l'émission d'informations 30 dites de leurre représentatives d'un emplacement fictif d'un fichier à télécharger en réponse à des requêtes de transferts de fichiers appartenant à une liste prédéterminée. Plusieurs cas sont à distinguer: si le serveur (ou servent) met en oeuvre le procédé de limitation de 5 transfert selon l'invention et qu'il reçoit une requête correspondant à un fichier protégé, le serveur (ou servent) transmet à l'utilisateur plusieurs réponses contenant chacune une adresse virtuelle (dite de leurre) et ne transmet pas la requête à un autre serveur, aucun téléchargement ne pouvant alors aboutir; - si le serveur (ou servent) met en oeuvre le procédé de limitation de transfert de fichier selon l'invention et que la requête ne correspond pas à un fichier protégé, le serveur transmet la requête à un autre serveur afin que cette dernière s'effectue normalement (ainsi le serveur est fonctionnel et s'intègre durablement au réseau); - si le réseau P2P est de type semi-centralisé et qu'aucun serveur ne met directement en oeuvre le procédé de limitation de transfert, c'est la présence de noeuds ou clients particuliers mettant en oeuvre cette limitation et connecté à un serveur qui va permettre cette limitation en proposant des réponses de leurre à des requêtes pour des titres protégés 20 qui noient les réponses réelles et téléchargeables. Préférentiellement, vingt voire cent réponses de leurre sont proposées. Le nombre de réponses de leurre peut être adapté en fonction notamment du fichier et/ou du client requérant pour correspondre à 95 % des réponses susceptibles d'être reçues par le requérant. Le nombre de réponses de 25 leurre peut être étalonné en temps réel en prenant en compte le nombre probable de réponses correctes susceptibles d'être reçues, ce nombre pouvant être estimé d'une manière quelconque et notamment par une observation du réseau. Ceci est possible notamment grâce au ciblage de l'action sur des fichiers prédéterminés et pour lequel le nombre de résultats de recherche est contrôlable avec les moyens du réseau selon des techniques connus en soi; - si le réseau P2P est de type décentralisé et qu'il utilise des servents qui ne mettent pas en oeuvre le procédé de limitation selon l'invention, une 5 requête de transfert de fichiers est transmise aux autres servents et notamment à un servent qui mettra en oeuvre cette limitation et qui répond à la recherche avec des noms de fichiers et des liens fictifs en grand nombre (préférentiellement, au moins 20 voire 100 fois pour correspondre comme indiqué précédemment à 95 % des résultats réels 10 que l'utilisateur est susceptible de recevoir). Dans ce cas, la rapidité de la réponse est essentielle pour le bon positionnement des réponses de limitation ou de leurre dans le logiciel de l'utilisateur. La figure 1 illustre une architecture de réseau P2P semi-centralisée dans lequel au moins un serveur met en oeuvre une limitation des transferts illicites 15 et/ou non autorisés de fichiers selon l'invention. Ce réseau comprend notamment: - un serveur 100 SL mettant en oeuvre ladite limitation; - deux serveurs 110 et 120 qui ne mettent pas en oeuvre le procédé de limitation; et - des noeuds clients 101, 102, 111 à 113, 121 et 122. Les noeuds 101 et 102 sont reliés au serveur 100 via respectivement des liaisons 103 et 104. Les serveurs 110 et 120 sont également reliés au serveur 100 via des liaisons respectivement 105 et 106. Le serveur 110 est également relié aux noeuds 111 à 113 ainsi qu'au serveur 120. Le serveur 120 est aussi relié aux noeuds 121 et 122. Chacune des liaisons filaires ou sans fil entre un serveur et un client ou entre deux serveurs est bidirectionnelle et est mise en oeuvre selon un protocole de type Internet compatible avec les réseaux P2P. Ces liaisons sont bien connues de l'homme du métier et ne seront pas décrites davantage. La figure 2 illustre une architecture de réseau décentralisée comprenant au moins un servent SL 200 mettant en oeuvre un algorithme de limitation des transferts illicites et/ou non autorisés de fichiers. Ce réseau P2P comprend également des servents (noeuds qui sont à la fois 5 clients et serveurs) 201 à 208. Le servent 200 est connecté aux servents 201, 202, 205, 206. Le servent 201 est également connecté aux servents 202 et 208. Le servent 202 est connecté aux servents 203 à 205. Le servent 204 est connecté également aux servents 203 et 207. Le servent 207 est aussi connecté aux servents 205 et 206. Chacune des liaisons filaires ou sans fil entre deux servents est bidirectionnelle et est mise en òuvre selon un protocole compatible avec les réseaux P2P. Ces liaisons sont bien connues de l'homme du métier et ne seront pas décrites davantage. La figure 3 illustre une architecture de réseau semi-centralisée comprenant 15 trois serveurs 310 à 312 reliés entre eux. Le réseau comprend également deux noeuds clients 320 et 322 connectés au servent 311 et un noeud client 323 connecté au serveur 312. Le serveur 310 est connecté lui-même: - à un client 320 qui comprend des fichiers réels susceptibles 20 d'être téléchargés; et - des noeuds clients 300 à 305 mettant en oeuvre un algorithme de limitation de transfert illicite et/ou non autorisé de fichiers sur un réseau P2P, compatible avec l'invention. Chacune des liaisons filaires ou sans fil entre un client et un serveur ou 25 entre deux serveurs est bidirectionnelle et est mise en oeuvre selon un protocole compatible avec les réseaux P2P. Ces liaisons sont bien connues de l'homme du métier et ne seront pas décrites davantage. La figure 4 illustre schématiquement un serveur 100 de limitation de transfert de fichiers tel qu'illustré en regard de la figure 1. Le serveur 100 comprend, reliés entre eux par un bus d'adresses et de données 401: - un processeur 400; - une mémoire vive 420; - un disque dur 410; - une interface homme-machine 450; et - une interface réseau 230. Chacun des éléments illustrés en figure 4 est bien connu de l'homme du métier. Ces éléments communs ne sont donc pas décrits ici. On observe que le mot " registre " utilisé dans toute la description désigne dans chacune des mémoires mentionnées, aussi bien une zone de mémoire de faible capacité (quelques données binaires) qu'une zone mémoire de grande capacité (permettant de stocker un programme entier ou l'intégralité d'une base de données). Le disque dur 410 comprend notamment: - un programme " Prog " 411; - une liste de fichiers protégés 412; et - une liste de messages comprenant des adresses de leurre 413. Les algorithmes mettant en oeuvre les étapes des procédés décrits ciaprès, 20 notamment en regard des figures 5 à 7 sont stockés dans le disque dur 410 associé au serveur 100 mettant en oeuvre ces étapes. la mise sous tension, le processeur 400 charge et exécute les instructions de ces algorithmes. La mémoire vive 420 conserve des données, des variables et des résultats intermédiaires de traitement et comprend notamment: - le programme " Prog " 421 de fonctionnement du processeur 400 chargé à la mise sous tension du serveur 100; - une liste de fichiers protégés 422 qui correspond à la liste 412; - une liste de serveurs 423 connectée au serveur 100 (c'est-àdire des identificateurs des serveurs 110 et 120 selon la figure 1); 30 des messages transmis, dans un registre 424; et - des messages reçus, dans un registre 425. L'interface homme-machine 450 comprend notamment un écran et un clavier permettant à l'utilisateur du serveur 100 de dialoguer avec cet appareil. L'interface réseau 230 permet une connexion avec les noeuds voisins du serveur 100 et notamment ici via les liaisons 103 à 106. Le serveur 200 illustré en regard de la figure 2 possède une architecture tout à fait similaire au serveur 100 et ne sera pas décrit davantage. Les clients 300 à 305 illustrés en regard de la figure 3 et mettant en oeuvre, selon l'invention, une limitation des transferts illicites et/ou non autorisés de 10 fichiers ont une architecture similaire au serveur 100 à l'exception: - de la mémoire vive qui ne comprend pas de liste de serveurs; et - de l'interface réseau qui permet simplement une connexion vers un serveur. La figure 5 présente un protocole de communication entre un noeud 15 requérant 101, le serveur SL 100, le serveur 110 et le client 111 dans le réseau P2P illustré en regard de la figure 1. On suppose que le serveur 100 comprend une liste de fichiers qui ne sont pas autorisés pour le téléchargement au sein du réseau P2P. titre illustratif, cette liste comprend un premier fichierficl et ne comprend pas un second fichierfic2. 20 Au cours d'une première étape, le requérant 101 transmet une requête 500 de recherche du fichierficl au serveur 100. la réception de cette requête 500, au cours d'une étape d'analyse 501, le serveur 100 détermine si le fichier ficl appartient ou non à la liste des fichiers non-autorisés pour un transfert. Ici, fici appartient à cette liste et ainsi, au cours d'une étape 502, le serveur va préparer N messages de leurre contenant chacun une adresse de leurre respectivement @Leurrel à @LeurreN au cours d'une étape 502. La valeur du nombre N est supérieure à vingt et, en variante, à cent. Selon encore une autre variante correspondant, par exemple, à un fonctionnement dans un mode dégradé 30 ou si encore, par un moyen quelconque, on sait que la probabilité pour un requérant d'obtenir au moins une réponse correcte est très proche de zéro, le nombre N pourra être inférieur à vingt. La valeur de N est fixe ou étalonnée en temps réel ou sur requête en fonction notamment de l'état du réseau ou du fichier à télécharger, du nombre de 5 noeuds mettant en oeuvre l'invention et/ou de tout autre critère visant à optimiser le choix de cette valeur de N de sorte que le requérant choisisse selon une grande probabilité (supérieure ou égale, par exemple, à 0,95) un emplacement fictif de leurre. Puis au cours d'étapes 5031 à 503N, le serveur 100 transmet des réponses 10 au requérant 101 contenant une adresse fictive de leurre correspondante, respectivement @Leurre] à @LeurreN, telle que préparée au cours de l'étape 502. la réception de chaque réponse, le noeud 101 affiche une synthèse sur son écran. Ainsi, la réponse 5031 ayant été reçue, au cours d'une étape 5041, le 15 noeud 101 affiche l'adresse @Leurrel correspondant au leurre reçu. Selon le mode de réalisation décrit en regard de la figure 1, le noeud 101 est connecté directement au serveur 100 qui n'a pas retransmis la requête à d'autres serveurs. Le requérant 101 reçoit donc les N réponses contenant respectivement les adresses @Leurrel à @LeurreN qui seront les seules affichées 20 lors des étapes 5041 à 504N si le noeud 101 n'est pas connecté à des serveurs autres que le serveur 100. L'utilisateur du noeud 101 va donc demander le fichier fiel à l'adresse de leurre reçu, cet utilisateur n'ayant pas d'autre choix. Ainsi, au cours d'une étape 5051, le noeud 101 transmet une requête à l'adresse fictive de leurre requise par l'utilisateur. Cette adresse n'existant pas ou, 25 si elle existe, le chemin défini pour retrouver le fichier fiel n'ayant qu'une probabilité quasi-nulle d'exister, aucune réponse ne sera fournie au noeud 101. l'expiration d'une temporisation lancée à l'étape 5051, au cours d'une étape 5061, le noeud 101 indique l'échec de la requête sur un écran d'affichage. Les étapes 5051 et 5061 peuvent être réitérées avec d'autres adresses de 30 leurre parmi celles reçues précédemment et proposées à l'utilisateur lors des étapes d'affichage. Néanmoins, comme précédemment, toutes les requêtes de transfert de fichier correspondant à une adresse de leurre, elles aboutiront toutes à un échec. Le fichier requis ne pourra donc pas être téléchargé. En résumé, le requérant 101 a transmis au serveur 100 une requête de 5 recherche de fichier non autorisée pour une transmission et le serveur 100 n'a pas transmis cette requête à d'autres serveurs, et au contraire, a répondu au requérant par N adresses permettant de leurrer ce dernier. Ainsi, la requête de transfert n'aboutissant pas, le transfert du fichierficl n'a pu avoir lieu. Ensuite, au cours d'une étape 507, le noeud 101 requiert la recherche d'un 10 fichierfic2 par un message transmis au serveur 100. Puis, au cours d'une étape 508, le serveur 100 vérifie si le fichier fic2 correspond à un fichier présent dans la liste des fichiers non autorisés au transfert, cette liste étant mémorisée dans le registre 422. Ici, le fichierfic2 n'appartenant pas à cette liste, au cours d'une étape 509, 15 le serveur 100 transmet la requête de recherche du fichierfic2 au serveur auquel il est relié et notamment au serveur 110. Puis, au cours d'une étape 510, le serveur 110, en effectuant une recherche du fichier fic2, identifie un emplacement du fichier fic2 dans un noeud client 111 auquel il est relié, ce client 111 ayant au préalable transmis au serveur 110 la liste 20 complète des fichiers qu'il peut transférer. Ainsi, au cours d'une étape 511, le serveur 110 construit puis transmet un message de réponse contenant un identifiant de l'emplacement du fichier fic2 (adresse IP du noeud 111 et emplacement précis au sein du noeud 111) au serveur 100. la réception de la réponse 511, au cours d'une étape 512, le serveur 100 retransmet directement cette réponse au noeud 101. Ensuite, au cours d'une étape 513, le noeud 101 extrait de la réponse 512 l'information d'emplacement (adresse IP du noeud 111 et chemin d'accès au sein du noeud 111) du fichierfic2 et l'affiche sur l'écran du noeud 501. L'utilisateur du 30 noeud 101 peut alors demander la transmission du fichierfic2 correspondant à cet emplacement. Ainsi, au cours d'une étape 514, le noeud 101 transmet une requête du fichier fic2 directement au noeud 111 dont l'adresse IP est déterminée au cours de l'étape 513. la réception de ce message, au cours d'une étape 515, le noeud 111 transfère directement le fichierfic2 au noeud 501. Ensuite, au cours d'une étape 516, le noeud 101 affiche une opération de réussite du transfert. En résumé, le noeud 101 ayant demandé au serveur 100 le transfert d'un fichier autorisé, le serveur 100 a permis le transfert effectif de ce fichier sans 10 perturber le réseau P2P. En variante, si le serveur 100 a connaissance d'une adresse réelle associé à un fichier fiable et autorisé pour un transfert, le serveur relaie non seulement une requête de recherche de ce fichier mais y répond par une ou plusieurs réponses correctes (et non de leurre) ce qui permet de pallier une éventuelle pollution en 15 favorisant un ou plusieurs liens. Un protocole tout à fait similaire est mis en oeuvre lorsque le réseau P2P possède une architecture de réseau décentralisée et lorsque le servent mettant en oeuvre l'algorithme de limitation reçoit d'un autre servent une requête de recherche d'un fichier à télécharger initiée par un noeud et relayée par un ou 20 plusieurs servents. La figure 6 illustre un protocole de communication entre différents éléments présentés en regard du réseau de la figure 2 notamment le servent 200 mettant en oeuvre un algorithme de limitation de transfert de fichier, et les servents 201, 205, 207 et 208. Au cours d'une première étape 600, le servent 207 agissant en tant que client requiert la recherche d'un fichierficl en transmettant au servent voisin 205 un message correspondant. Au cours d'une étape 601, le servent 205 agissant en temps que serveur recherche le fichier fiel, qui ici, à titre illustratif, n'appartient pas à ses bases 30 données de fichiers connus. Puis, au cours d'une étape 602, le servent 205 transmet une requête de recherche du fichierficl au noeud 200. En parallèle, au cours d'une étape 603, le noeud 205 transmet également une même requête au serveur ou servent 201. A la réception de la requête 602, au cours d'une étape 604, le serveur 200 5 prépare N leurres correspondant au fichier recherchéficl, et destinés au requérant 207 puis il envoie successivement N messages en réponse à la requête 602 à destination du requérant via le serveur 205. Ainsi, à titre illustratif, au cours d'une étape 605, un premier message de réponse contenant une première adresse de leurre est transmise au serveur 205 qui 10 la répercute au cours d'une étape 606 au servent 207 et ainsi de suite jusqu'à la transmission d'une réponse 607 contenant une Nième adresse de leurre que le serveur 205 répercute au cours d'une étape 608 au serveur 207. la réception de la requête 603, au cours d'une étape 605, le serveur 201 effectue une recherche du fichierficl qui, à titre illustratif, n'est pas présent dans 15 les bases de données de fichiers connus du serveur 201. Puis, au cours d'une étape 614, le serveur 201 transmet une requête de recherche du fichierficl aux serveurs voisins et notamment au serveur 208. Le serveur 200 est adapté à un traitement rapide des requêtes qu'il reçoit, de sorte que la préparation des leurres et la transmission des réponses soient 20 effectuées le plus tôt possible après réception d'une requête de recherche de fichier. Ainsi, suite à l'émission de la requête 600, des réponses en provenance du serveur 200 arrivent en grand nombre et en priorité au requérant 207, avant que d'autres serveurs n'aient eu le temps de répondre. De cette manière, il est fort probable que la requête 614 parvienne au serveur 208 après que la réponse 608 ait été reçue par le noeud 207. Ainsi, au cours d'une étape 609, le noeud 207 affiche le résultat correspondant aux N réponses reçues précédemment, notamment au cours des étapes 606 et 608. Le nombre N de réponses de leurre transmises par le serveur 200 est par 30 ailleurs choisi pour être relativement grand et préférentiellement dimensionné pour être égal à au moins vingt fois le nombre de réponses effectif correct contenant des adresses réelles du fichier fiel. Ainsi, même si des servents répondent en même temps que le serveur 200, les réponses de ces servents seront noyées parmi toutes les réponses de leurre reçues en parallèle. Au cours de l'étape 609 d'affichage, l'utilisateur du noeud 207 va donc choisir avec une forte probabilité un emplacement de fichier correspondant à un leurre. Le noeud 207 transmet alors une requête 610 contenant une adresse de leurre qui n'aboutit pas. Après expiration d'une temporisation lancée lors de la requête 610, au cours d'une étape 611 d'affichage, le noeud 207 indique un échec de la requête 610 et affiche la liste mise à jour des emplacements possibles de fichiers. Puis, au cours d'une étape 612, une nouvelle requête correspondant à une adresse fictive de leurre est transmise par le servent 207. De même que 15 précédemment, cette requête n'aboutit pas, et à l'expiration d'une temporisation lancée lors de cette requête, au cours d'une étape 613, le servent 207 indique l'échec de la requête. Après plusieurs échecs successifs, l'utilisateur du noeud 207 abandonne probablement la recherche du fichierficl. Parallèlement aux étapes 609 à 613, après réception de la requête 614, le serveur 208 effectue une recherche du fichier ficl au cours d'une étape 615 et identifie un emplacement d'un tel fichier. Le serveur 208 répond alors au serveur 201 au cours d'une étape 616. Cette réponse est répercutée d'abord vers le servent 205 au cours d'une étape 617 25 puis vers le servent requérant 207 au cours d'une étape 618. Ainsi, la réponse 618 est reçue par le serveur 207 alors que l'utilisateur du noeud 207 a déjà abandonné la recherche du fichierficl. Elle n'est donc pas prise en compte. La figure 7 décrit un algorithme mis en oeuvre par un serveur destiné à limiter le nombre de requêtes de transfert illicite ou non autorisé de fichiers. Ce serveur est par exemple l'un des serveurs 100 ou 200 illustrés respectivement en regard des figures 1 et 2. Au cours d'une étape 700, le serveur initialise les variables mises en oeuvre dans l'algorithme, ainsi que toutes les données nécessaires au bon fonctionnement 5 de cet algorithme. Au cours de cette étape 700, une base de données de fichiers non autorisés pour le transfert est notamment mis à jour par l'utilisateur du serveur. Ensuite, au cours d'une étape 701, le serveur attend puis reçoit une requête de recherche de fichierfic contenant un identifiant de ce fichierfic. Puis, au cours d'un test 702, le serveur détermine si le fichier fic est un fichier protégé ou non. En d'autres termes, il vérifie si l'identifiant appartient ou non à la liste de fichiers protégés ou plus généralement non autorisés pour un transfert contenu dans sa mémoire (mémoire 422 dans le cas du serveur 100) . Dans la négative, le fichier n'est pas protégé, et au cours d'une étape 703, 15 le serveur transmet cette requête vers les serveurs du réseau P2P, auquel il est relié. Après l'exécution de l'étape 703, l'étape 701 est réitérée. Si le résultat du test 702 indique que la requête 701 concerne un fichier protégé, il est nécessaire, pour que la limitation ait de bonnes chances de succès, de transmettre plusieurs réponses de leurre au client. Ainsi, au cours d'une étape 704, le serveur prépare N réponses différentes contenant chacune une adresse de leurre, N étant, par exemple, égal à 20 ou 100 et préférentiellement déterminé de sorte qu'il soit égal à environ au moins vingt fois le nombre de réponses susceptibles d'être reçues par le client (ce nombre étant déterminé d'une manière quelconque notamment par analyse du trafic sur le 25 réseau ou simulation) . Le nombre N est fixe ou évolue en temps réel en fonction d'événements (par exemple, écoulement d'une temporisation ou requête humaine). Il est dépendant ou non du fichier requis. Ensuite, au cours d'une étape 705, le serveur transmet au client les N réponses préparées. A la réception de ces N réponses, le client affiche ces 30 réponses qui seront probablement choisies par l'utilisateur du client. Puis, l'étape 701 est réitérée. La figure 8 décrit un protocole de communication entre un client 320, un serveur 310 et des clients adaptés à fournir des réponses de leurre à des requêtes de recherche de fichier 300 et 301 tel qu'illustrés en regard de la figure 3. Au cours d'une étape préalable, les clients 300 et 301 préparent des leurres respectivement au cours d'étapes 800 et 802 puis transmettent au serveur 310 une liste d'emplacements de leurre respectivement au cours d'étapes 801 et 803. Parallèlement, un client 804 quelconque transmet une liste d'adresses de fichiers au serveur 310, ces emplacements de fichiers correspondant à des 10 emplacements de fichiers réels pouvant être transférés à un autre client du réseau P2P. Au cours ou immédiatement après chacune des étapes 801, 803 et 804, le serveur 310 met à jour ses bases de données d'emplacements de fichiers en fonction des listes de fichiers reçus. Ainsi, après mise à jour, ces bases de données 15 contiennent notamment des adresses de leurres qui apparaissent, pour le serveur 310, comme des adresses réelles correspondant à un fichier pouvant être téléchargé et qui pourront donc être utilisées pour construire des réponses à des requêtes de recherche de fichiers correspondant. Ensuite, à titre, illustratif, au cours d'une étape 805, le client 320 transmet 20 une requête de recherche de fichier Ficl au serveur 310. Au cours d'une étape 806, le serveur 310 effectue dans ses bases de données une recherche de fichier correspondant à Ficl et identifie le fichier Fici dans les listes de leurre transmises respectivement par les clients 300 et 301 et dans la liste de fichiers réels transmise par le client 804. Ainsi, au cours des étapes 807 à 808, le serveur 310 transmet au client 320 N réponses de leurre correspondant à chacun des fichiers Ficl identifiés par ces listes transmises précédemment. En parallèle, au cours d'une étape 809, le serveur 310 transmet également une réponse contenant une adresse réelle de fichier Ficl. A la réception des réponses, le client 320 affiche l'intégralité de ces dernières, en l'occurrence les N+1 réponses reçues dont N réponses de leurre et une réponse de fichier réel. En effet, le réseau P2P est tel que le serveur 310 est relié à N clients susceptibles d'émettre des réponses de leurre correspondant au 5 fichier Ficl, N étant choisi pour être supérieur ou égal à vingt fois le nombre de réponses susceptibles de parvenir au client 320. Selon une variante non représentée, le serveur 310 est relié à un client qui, pour chaque fichier non autorisé pour un transfert, lui transmet N emplacements *de leurre distincts. Les réponses sont donc affichées au cours d'une étape 810 par l'écran du client 320. L'utilisateur du client 320 choisit parmi les N+1 réponses reçues, une première réponse qui par exemple correspond au premier leurre reçu. Il effectue donc une requête à l'adresse du premier leurre reçu qui n'aboutit pas. l'expiration d'une temporisation lancée lors de la requête 811, au cours d'une étape d'affichage 812, le client indique un échec de la requête et affiche les N réponses restantes. Ainsi, l'utilisateur du client 320 choisit successivement P fichiers correspondant à des leurres. Le client 320 émettant les requêtes correspondantes 20 qui n'aboutissent pas. Après une dernière requête 813 et l'expiration de la temporisation du correspondant, au cours d'une étape 814, le client 320 affiche l'échec de cette dernière requête ainsi que les adresses de fichiers correspondant au fichierficl et si P est suffisamment grand, l'utilisateur décide d'abandonner la recherche de ce fichier. En conclusion, ici, le processus de limitation de transfert 25 des fichiers non autorisés ou illicites a bien fonctionné. La figure 9 illustre un algorithme de génération de leurre mis en oeuvre par un client 300 à 305 tel qu'illustré en regard de la figure 3. Au cours d'une étape d'initialisation 900, le client met à jour des variables et notamment une liste des fichiers non autorisés pour le transfert. Puis, au cours d'une étape 901, pour chacun des fichiers enregistrés dans la liste des fichiers non autorisés pour un transfert, le client prépare N leurres destinés à être transmis lors d'une requête de recherche de fichiers. Un leurre est défini par un emplacement comprenant une adresse de noeud et/ou un chemin 5 d'accès fictif. Les adresses et chemins peuvent être générés aléatoirement ou préenregistrés dans une base de données. Le nombre N est, par exemple, égal à vingt ou cent. Il peut être étalonné selon de nombreux critères (nature du fichier concerné, état du réseau, état du fichier sur le réseau, nombre et répartition des clients ou serveurs mettant en oeuvre l'invention,...). Une mise à jour du 10 paramètre N est effectuée partiellement ou complètement au niveaux des noeuds mettant en oeuvre l'invention; elle est mise en oeuvre sur événement (notamment écoulement d'une temporisation, intervention humaine,...). Ensuite, au cours d'une étape 902, le client transmet au serveur auquel il est rattaché (serveur 310), la liste de tous les leurres ainsi préparés. Puis, au cours d'une étape 903, le client lance une temporisation égale, par exemple, à vingt minutes permettant une mise à jour des adresses de leurre. l'expiration de cette temporisation, l'étape 901 est réitérée. Bien entendu, l'invention n'est pas limitée aux exemples de réalisation mentionnés ci-dessus. Ainsi, l'invention s'applique à tout type d'architecture et de protocole de réseaux P2P qui permettent des téléchargements effectués directement entre utilisateurs et gérés par le réseau et non par un seul serveur. L'invention concerne notamment les réseaux P2P centralisés ou semicentralisés, les réseaux P2P décentralisés, ainsi que dans toutes les variantes mixant ces deux types 25 d'architectures. Dans le cas des réseaux centralisés ou semi-centralisés, l'invention peut être mise en oeuvre par des clients et/ou par des serveurs dédiés, générant et/ou contenant des listes d'emplacement de leurres. L'invention n'est pas non plus limitée au transfert de fichiers audiovisuels, mais concerne tous les fichiers susceptibles d'être non autorisés pour un transfert, 30 par exemple des fichiers bénéficiant du droit d'auteur, des fichiers interdits pour le transfert par la loi (par exemple, des fichiers contraires aux bonnes moeurs ou pouvant nuire à l'ordre public),... On notera aussi que l'invention ne se limite pas à une implantation purement matérielle mais qu'elle peut aussi être mise en oeuvre sous la forme 5 d'une séquence d'instructions d'un programme informatique ou toute forme mixant une partie matérielle et une partie logicielle. Dans le cas o l'invention est implantée partiellement ou totalement sous forme logicielle, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou 10 non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur. On note également que l'invention ne se limite pas à une mise en oeuvre concernant l'émission d'adresses de leurre complètement fictives mais peut aussi correspondre à des adresses contenant des fichiers d'avertissement au client et/ou 15 contenant une offre d'achat. L'invention est adaptée à tous types de réseaux et plus particulièrement aux réseaux filaires, aux réseaux mobiles de toute taille. REVENDICATIONS 1. Procédé de limitation de transfert de fichiers informatiques dans un réseau de communication pair à pair (" peer to peer "), au moins un premier noeud 5 (101,207) dudit réseau étant susceptible de diffuser vers au moins un second noeud (100, 205, 200, 310) dudit réseau au moins une requête (500, 600, 805) de recherche d'un fichier (Ficl) à transférer, caractérisé en ce qu'au moins un desdits seconds noeuds est adapté pour transmettre au moins une réponse (5031, 503N, 605 à 608, 807, 808), dite de 10 leurre, comprenant une information représentative d'un emplacement fictif (@Leurrel, @LeurreN) dudit fichier à transférer. 2. Procédé selon la revendication 1, caractérisé en ce que ledit ou lesdits seconds noeuds sont adaptés pour transmettre au moins vingt réponses distinctes parmi lesdites réponses de leurre. 3. Procédé selon la revendication 2, caractérisé en ce que ledit ou lesdits seconds noeuds sont adaptés pour transmettre au moins cent réponses distinctes parmi lesdites réponses de leurre. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, dans au moins un desdits seconds noeuds, on met en oeuvre les étapes 20 suivantes: - réception de ladite requête de recherche; et - transmission vers ledit premier noeud d'une réponse de leurre, comprenant une information représentative d'un emplacement fictif dudit fichier à transférer, si au moins un premier critère prédéterminé 25 de limitation de transfert est vérifié. 5. Procédé selon la revendication 4, caractérisé en ce qu'un desdits critères prédéterminés est l'appartenance d'un identificateur dudit fichier à transférer à une liste prédéterminée d'au moins un fichier non autorisé pour un téléchargement. 6. Procédé selon l'une quelconque des revendications 4 et 5, caractérisé en ce que ledit second noeud met en oeuvre une étape de vérification (501, 508) que ladite requête répond audit ou auxdits premiers critères prédéterminés. 7. Procédé selon la revendication 4, caractérisé en ce que ledit second noeud 5 retransmet (509) ladite requête de recherche (507) à des noeuds (110) auxquels il est relié si lesdits premiers critères ne sont pas vérifiés. 8. Procédé selon l'une quelconque des revendications 4 à 7, caractérisé en ce que ledit second noeud met en oeuvre une étape de génération de ladite information représentative d'un emplacement fictif dudit fichier à transférer après ladite 10 réception de ladite requête de recherche. 9. Procédé selon l'une quelconque des revendications 4 à 7, caractérisé en ce que ledit second noeud met en oeuvre une étape de génération (502, 604) d'une information représentative d'un emplacement fictif pour chacun des fichiers appartenant à ladite liste prédéterminée d'au moins un fichier non autorisé pour un 15 téléchargement avant ladite réception de ladite requête de recherche. 10. Procédé selon l'une quelconque des revendications 4 à 9, caractérisé en ce que ledit réseau possède au moins en partie une architecture clientserveur et en ce que ledit second noeud est un serveur dudit réseau. 11. Procédé selon la revendication 10, caractérisé en ce qu'au moins un 20 troisième noeud (300, 301) transmet (801, 803) audit second noeud (310) au moins une liste (Liste(@Leurre)) d'emplacements de fichiers fictifs et en ce que ledit second noeud met à jour (801, 803) une liste de localisation de fichiers susceptibles d'être téléchargés en fonction de ladite liste d'emplacements de fichiers fictifs. 12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce que ledit réseau possède une architecture décentralisée. 13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que lesdits fichiers sont des fichiers de type audiovisuel, contenant des informations représentatives de son et/ou d'images. 14. Procédé selon l'une quelconque des revendications I à 13, caractérisé en ce que lesdits fichiers sont des fichiers de type contenant du texte et/ou un programme d'ordinateur. 15. Serveur (100, 200) adapté à une limitation de transfert de fichiers 5 informatiques dans un réseau de communication pair à pair (" peer to peer "), au moins un premier noeud (101, 207, 205) dudit réseau étant susceptible de diffuser vers ledit serveur au moins une requête de recherche (500, 600, 602) d'un fichier (fic]) à transférer, caractérisé en ce que ledit serveur comprend des moyens de transmission d'au 10 moins une réponse dite de leurre, comprenant une information représentative d'un emplacement fictif dudit fichier à transférer. 16. Serveur selon la revendication 15, caractérisé en ce que ledit serveur comprend: - des moyens de réception de requêtes de recherche; et - des moyens de transmission vers ledit premier noeud d'au moins une réponse dite de leurre, comprenant une information représentative d'un emplacement fictif dudit fichier à transférer, si au moins un premier critère prédéterminé de limitation de transfert est vérifié. 17. Noeud (300, 301) de type client, adapté à une limitation de transfert de 20 fichiers informatiques dans un réseau de communication pair à pair (" peer to peer ") comprenant des clients et des serveurs, au moins un premier noeud (320) dudit réseau étant susceptible de diffuser vers au moins un second noeud (310) dudit réseau au moins une requête de recherche d'un fichier à transférer, caractérisé en ce que ledit noeud de type client comprend: - des moyens de génération (800, 802) d'au moins une information dite de leurre, représentative d'un emplacement fictif de fichiers prédéterminés susceptibles d'être requis pour un transfert dans ledit réseau; - des moyens de transmission (801, 803) de ladite ou desdites 30 informations de leurre vers au moins un desdits seconds noeuds, de sorte à ce que ledit ou lesdits seconds noeuds puissent prendre en compte ladite ou lesdites informations de leurre pour répondre à ladite ou auxdites requêtes de recherche d'un fichier à transférer. 18. Produit programme d'ordinateur comprenant des éléments de programme, 5 enregistrés sur un support lisible par au moins un microprocesseur, caractérisé en ce que lesdits éléments de programme contrôlent le ou lesdits microprocesseurs pour que, dans un réseau de communication pair à pair (" peer to peer "), au moins un premier noeud dudit réseau étant susceptible de diffuser vers au moins un second noeud dudit réseau au moins une requête de recherche d'un fichier à 10 transférer, ils effectuent une étape de transmission d'au moins une réponse dite de leurre, comprenant une information représentative d'un emplacement fictif dudit fichier à transférer. 19. Produit programme d'ordinateur, caractérisé en ce que ledit programme comprend des séquences d'instructions adaptées à la mise en oeuvre d'un procédé 15 de limitation de transfert de fichiers selon l'une quelconque des revendications 1 à 14 lorsque ledit programme est exécuté sur un ordinateur.