FR 2852419 A1 20040917 FR 0303214 A 20030314 i La présente invention se rapporte au traitement d'une transaction électronique entre un dispositif client et un dispositif serveur, via un dispositif intermédiaire de paiement équipé d'un cache. Elle trouve une application générale dans les transactions 5 électroniques au sein d'un réseau informatique distribué selon une architecture client/serveur ou poste à poste, et plus particulièrement dans la centralisation du traitement des paiements électroniques au niveau d'un dispositif servant d'intermédiaire de paiement pour les transactions électroniques mises en oeuvre entre des dispositifs client et serveur au sein d'un réseau informatique distribué. 10 On connaît déjà un procédé de traitement d'une transaction électronique entre un dispositif client et un dispositif serveur dans lequel un dispositif intermédiaire reçoit d'une part un paiement émanant du dispositif client pour la réalisation de la transaction, et effectue d'autre part le paiement correspondant auprès du dispositif serveur à l'issue de la transaction. Un tel procédé est relativement satisfaisant dans la mesure o il permet à un dispositif client de n'établir qu'un seul moyen de paiement (dont la configuration est généralement coûteuse en temps de calcul) avec un dispositif intermédiaire au lieu d'en établir un avec chacun des dispositifs serveurs auquel il veut régler des achats, De même, un tel dispositif intermédiaire de paiement 20 permet aux dispositifs serveurs de ne recevoir des paiements que du dispositif intermédiaire de paiement au lieu d'en recevoir de chacun des dispositifs clients. Néanmoins, un tel procédé pose un problème lorsque la transaction entre le dispositif serveur et le dispositif client n'est pas (ou difficilement) effectuée après l'opération de paiement du dispositif client auprès du dispositif 25 intermédiaire. Tel peut être le cas lorsque le dispositif serveur n'est pas (ou difficilement) accessible, notamment lorsque que ledit dispositif serveur n'est pas en fonctionnement ou n'est pas connecté au réseau. Tel peut aussi être le cas lorsque la bande passante de la connexion 30 du dispositif serveur est relativement faible ou peu importante par rapport à la quantité de données demandées audit dispositif serveur. La présente invention apporte justement une solution au problème de disponibilité des dispositifs serveurs délivrant des données et/ou services dans un réseau de communication de type client/serveur ou poste à poste. Elle porte sur un procédé de traitement d'une transaction électronique 5 entre un dispositif client et un dispositif serveur sur un réseau de communication, ledit procédé étant mis en oeuvre au sein d'un dispositif intermédiaire du réseau de communication servant d'intermédiaire de paiement pour ladite transaction. Selon une définition générale de l'invention, le procédé comprend, au niveau du dispositif intermédiaire, les étapes suivantes: - en provenance du dispositif client, recevoir une requête de livraison d'un fichier de données ayant une désignation choisie; - obtenir une table de correspondance entre une désignation d'un fichier de données, au moins un emplacement substitut de celui-ci, et au moins une condition clef pour la livraison du fichier de données à partir de l'un des 15 emplacements substituts; et - vérifier si au moins l'une des conditions clefs obtenues est vraie, et en cas de vérification positive, livrer à destination du dispositif client le fichier de données à partir de l'un des emplacements substituts. Ainsi, selon le procédé conforme à l'invention, le dispositif 20 intermédiaire joue le rôle de cache pour conserver des données choisies, ce qui permet d'améliorer la disponibilité de ces données, par exemple celles les plus demandées, lorsque le dispositif serveur est hors d'usage ou de faible bande passante. De plus, le procédé selon l'invention permet de diminuer la demande 25 envers les dispositifs serveurs et aussi de diminuer le temps de réponse pour les dispositifs clients. Selon une réalisation, dans laquelle la requête est en outre accompagnée d'un montant de paiement correspondant à la livraison, le procédé comprend en outre l'étape dans laquelle il est prévu d'établir la correspondance 30 avec un prix associé à la livraison dudit fichier de données, de comparer le montant du paiement ainsi reçu avec le prix de livraison, et en cas de comparaison négative de ne pas livrer le fichier de données à partir de l'un des emplacements substituts. Selon une autre réalisation, au moins une condition clef est définie en fonction de la fréquence des demandes, de l'obsolescence et/ou d'une caractéristique de chaque fichier de données à livrer. Selon encore une autre réalisation, au moins une condition clef est définie en fonction d'au moins une caractéristique du dispositif serveur. Par exemple, au moins une caractéristique du dispositif serveur participant à la définition d'une condition clef est la disponibilité du serveur et/ou la bande passante du serveur. Selon une autre réalisation, toutes les conditions clefs obtenues 10 doivent être vérifiées positivement pour que le fichier de données soit livré à partir de l'un des emplacements substituts. Selon encore une autre réalisation, la table de correspondance comprend au moins deux emplacements substituts ayant respectivement au moins une condition clef associée et au moins une condition clef associée à un 15 emplacement substitut n'est pas associé à au moins un emplacement substitut différent. En pratique, il est prévu d'entretenir et/ou mettre à jour la table de correspondance en fonction de la fréquence des demandes, de l'obsolescence et/ou d'une caractéristique de chaque fichier de données à livrer ou en fonction 20 de la disponibilité et/ou de la bande passante du serveur. La présente invention a également pour objet un dispositif de traitement d'une transaction électronique entre un dispositif client et un dispositif serveur sur un réseau de communication, ledit dispositif de traitement étant susceptible d'être incorporé dans un dispositif intermédiaire du réseau de 25 communication, servant d'intermédiaire de paiement pour ladite transaction. Selon une réalisation, le dispositif intermédiaire comprend: - des moyens de réception d'une requête de livraison d'un fichier de données ayant une désignation choisie; - une table de correspondance représentative d'une correspondance 30 entre une désignation d'un fichier de données, au moins un emplacement substitut de celui-ci, et au moins une condition clef pour la livraison du fichier de données à partir de l'un de ces emplacements substituts; et - des moyens de traitement aptes à accéder à la table, à vérifier si au moins l'une des conditions clefs pour la livraison du fichier de données associée audit fichier ainsi désigné est vraie et en cas de vérification positive, à livrer à destination du dispositif client le fichier de données à partir de l'un de ces emplacements substituts. La présente invention vise aussi un dispositif intermédiaire comportant des moyens adaptés à mettre en oeuvre un procédé de traitement tel que décrit brièvement ci dessus. L'invention vise aussi un dispositif intermédiaire comportant un 10 dispositif de traitement tel que décrit brièvement ci dessus. L'invention vise aussi un système de transaction électronique dans un réseau de communications comportant un dispositif intermédiaire tel que décrit brièvement ci dessus. L'invention vise aussi un support d'informations lisible par un système 15 informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, et comportant des instructions d'un programme d'ordinateur permettant la mise en oeuvre d'un procédé de traitement tel que décrit brièvement ci dessus, lorsque ce programme est chargé 20 et exécuté par un système informatique. L'invention vise aussi un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de traitement tel que décrit brièvement ci dessus, lorsque ce programme est chargé et exécuté par un système informatique. Les avantages et caractéristiques particulières propres aux dispositifs de traitement, aux dispositifs intermédiaires, au système de transaction électronique, au support d'information et au programme d'ordinateur étant les mêmes que ceux exposés ci-dessus concernant le procédé de traitement selon l'invention, ils ne seront pas rappelés ici. D'autres aspects et avantages de la présente invention apparaîtront plus clairement à la lecture de la description de modes particuliers de réalisation qui va suivre, cette description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés sur lesquels: - la figure 1 représente un système de paiement comprenant un dispositif intermédiaire de paiement dépourvu de cache; - la figure 2 représente, sous forme d'organigramme, les principales étapes mises en oeuvre par un dispositif intermédiaire équipé d'un cache, conformément à la présente invention; - la figure 3 représente, sous forme d'organigramme, le processus selon lequel le dispositif intermédiaire retourne un message d'erreur, conformément à la présente invention; - la figure 4 représente, sous forme d'organigramme, le processus selon lequel 10 le dispositif intermédiaire retourne une réponse au dispositif client en présence d'un paiement valide conforme à la présente invention; - la figure 5 représente, sous forme d'organigramme, le traitement d'une requête d'autorisation de livraison par un dispositif intermédiaire conforme à la présente invention; - la figure 6 représente, sous forme d'organigramme, les principales étapes de mise à jour de la table de correspondance, conformément à la présente invention; et - la figure 7 représente schématiquement un dispositif intermédiaire adapté pour mettre en oeuvre un procédé de transaction selon l'invention. En référence à la figure 1, une transaction électronique est mise en oeuvre entre un dispositif client C et un dispositif serveur S, via et au sein d'un dispositif intermédiaire de paiement IP, dépourvu de cache. Dans l'exemple décrit à la figure 1, le dispositif client C souhaite obtenir une image I en provenance du dispositif serveur S, mais le mécanisme 25 mis en oeuvre serait équivalent pour un autre type de transaction ou un autre type de document. L'image I est payante mais, comme décrit précédemment, le paiement n'est pas réalisé directement par le dispositif client C au profit du dispositif serveur S. Au contraire, le dispositif intermédiaire IP sert d'intermédiaire de 30 paiement entre le dispositif client C et le dispositif serveur S. Préalablement à tout achat auprès du dispositif serveur S, le dispositif client C émet une requête RAT d'autorisation de transaction à destination du dispositif intermédiaire IP. La requête RAT comporte l'adresse S du dispositif serveur S l'identificateur I de l'image I à obtenir; un montant de paiement MP; et au moins une pièce électronique Pj(C, IP) appartenant à l'ensemble des pièces électroniques utilisables par le client C pour réaliser un paiement auprès du dispositif intermédiaire IP. La réception d'une requête RAT d'autorisation de transaction est suivie par une étape au cours de laquelle le dispositif intermédiaire IP vérifie la validité du paiement associé à la requête RAT d'autorisation de transaction. Cette vérification s'effectue, dans le mode préféré de réalisation décrit 10 ici, en vérifiant si la au moins une pièce électronique Pj(C, IP) contenue dans la requête RAT d'autorisation permet de réaliser un paiement de montant MP, ce montant étant également compris dans la requête RAT d'autorisation. Ainsi, si le paiement est correct, le dispositif intermédiaire IP retourne une réponse contenant un accusé de réception OK, signifiant au client C qu'il 15 peut demander l'image l au serveur S. En revanche, si le paiement associé à la requête RAT d'autorisation de transaction n'est pas validé, le résultat du test est négatif. Ce test est alors suivi par une étape au cours de laquelle le dispositif intermédiaire IP notifie le dispositif client C d'une erreur. Après l'envoi de la requête RAT d'autorisation de transaction, le dispositif client C envoie au dispositif serveur S, une requête RDT de déclenchement de transaction, cette requête comportant l'identificateur I de l'image I à obtenir. Sur réception de la requête RDT de déclenchement de transaction, le 25 dispositif serveur S envoie au dispositif intermédiaire IP une requête RAL d'autorisation de livraison de l'image I au dispositif client C. Cette requête RAL d'autorisation de livraison comporte l'identificateur I de l'image I demandée par le dispositif client et l'identifiant du client C; et le montant de paiement MP1 demandé par le dispositif serveur S pour fournir 30 l'image I au dispositif client C. Sur réception de cette requête RAL d'autorisation de livraison, le dispositif intermédiaire IP vérifie s'il a reçu une requête RAT d'autorisation du dispositif client C pour obtenir l'image I. En d'autres termes, le dispositif intermédiaire IP vérifie si le paiement a bien été réalisé par le client C pour l'image I. Si tel est le cas, le dispositif intermédiaire IP envoie un message MVT de validité de la transaction au dispositif serveur S, ce message MVT de validité 5 de transaction comportant au moins une pièce Pk(IP, S) appartenant à l'ensemble des pièces électroniques utilisables par le dispositif intermédiaire IP pour régler le dispositif serveur S pour le montant MPI. Sur réception du message MVT de validité de la transaction, le serveur S vérifie la validité du paiement reçu en provenance du dispositif 10 intermédiaire IP à l'étape précédente, et transmet l'image I au dispositif client C lorsque ce paiement est validé. Comme on le verra plus en détail ci-après, lorsque le cache du dispositif intermédiaire peut être utilisé, la réponse du dispositif intermédiaire IP au dispositif client C contient non seulement un accusé réception du paiement 15 OKI, mais aussi le document ou l'image demandée I. Selon l'invention, le dispositif intermédiaire IP est équipé d'une table de correspondance TC entre une désignation d'un fichier de données, au moins un emplacement substitut de celui-ci, et au moins une information liée à une condition clef pour la livraison du fichier de données à partir de cet emplacement 20 substitut. Les emplacements substituts permettent de stocker des données gardées en cache. Par exemple les données conservées sont des images ou autres documents analogues. Une condition clef est un test permettant de déterminer si le dispositif 25 intermédiaire IP doit utiliser l'emplacement substitut pour la livraison du fichier de données. Par exemple une condition clef est que la fréquence de demande d'un fichier de données soit supérieure à une fréquence minimale. Le dispositif intermédiaire IP peut utiliser une ou plusieurs conditions clefs pour déterminer si 30 le fichier de données doit être livré à partir de l'emplacement substitut. La ou les conditions clefs peuvent dépendre du type ou des caractéristiques du fichier de données. Par exemple pour les images, seule une condition clef liée à la fréquence de demande du fichier de données peut être utilisée, tandis que pour les films deux conditions clefs peuvent être utilisées, l'une liée à la fréquence de demande du fichier de données et l'autre liée à la taille du fichier de données. En outre, si la table de correspondance TC contient plusieurs 5 emplacements substituts pour un même fichier de données, alors chacun de ces emplacements substituts peut être associé à un ensemble différent de conditions clefs. Par exemple, un emplacement substitut ayant un temps d'accès relativement long peut avoir une condition clef comparant la fréquence de 10 demande d'un fichier de données à une fréquence minimale relativement faible, tandis qu'un deuxième emplacement substitut ayant un temps d'accès plus court peut avoir une condition clef comparant la fréquence de demande d'un fichier de données à une fréquence minimale plus élevée. Quand plusieurs emplacements substituts existent pour un même 15 fichier de données, la table de correspondance TC comprend l'ordre d'utilisation de ces emplacements substituts. Outre des données à conserver, la table de correspondance TC contient l'ensemble des informations nécessaire au fonctionnement d'un cache. Par exemple, la table TC présente la structure suivante 20 Identifiant Fréquence Prix Validité Image image ID demande FD PX VL I Image_1 5 Image_2 50 1 E 24h image_2.jpg La première colonne de la table de correspondance TC contient les identifiants ID de chaque image I. L'identifiant ID appartient au groupe formé par un nom, une adresse de type URI ou tout autre identifiant de l'image à livrer. La deuxième colonne de la table TC contient la fréquence FD des demandes de chaque image. Cette fréquence FD peut être un simple nombre reflétant le nombre de requêtes pour cette image, ou peut contenir la date de chaque demande ou toute autre information donnant une indication de la quantité de demandes de cette image. Cette fréquence FD permet d'évaluer pour cette image une condition clef liée à la fréquence de requêtes. La troisième colonne de la table TC contient le prix PX de chaque image, afin que le dispositif intermédiaire puisse vérifier le prix payé par le dispositif client. La quatrième colonne de la table TC contient la durée de validité VL de chaque image, afin que l'intermédiaire sache quand il doit charger une nouvelle version de l'image correspondante. Enfin la cinquième colonne de la table TC contient l'image I elle10 même. La cinquième colonne forme ainsi les emplacements substituts du cache destinés à contenir les images à livrer. En pratique, les deux premières colonnes sont renseignées. Les autres colonnes ne sont renseignées que si l'image est effectivement conservée dans le cache. Les images ainsi conservées dans la table TC peuvent être retournées au dispositif client C et éviter ainsi les requêtes de téléchargement vers des dispositifs serveurs indisponibles. La figure 2 représente les principales étapes E100 à E185 mises en oeuvre par un dispositif intermédiaire IP équipé d'une table TC au cours d'une 20 transaction conformément à la présente invention. Dans le mode préféré de réalisation décrit ici, les paiements s'effectuent au moyen du système PayWord tel que proposé par Rivest et Shamir. Une description de ce système peut être consultée à l'adresse 25 Internet http://theory.Ics.mit.edu/-rivest/RivestShamir-mpay.ps. Ce système consiste, d'une manière générale, à générer récursivement, à partir d'un nombre aléatoire Pn et d'une fonction de hachage h (en anglais Hash function), une suite de pièces électroniques Pn Pn-1, ..., Po par la formule P-1. = h(P1). Cette fonction de hachage a la particularité de ne pas être réversible de telle sorte qu'il est en pratique impossible, à partir d'un nombre Pn-1, de retrouver le nombre précédent P1. L'extrémité P0 de la chaîne ainsi obtenue est appelée pièce racine (en anglais Root Coin) et permet de vérifier l'authenticité des autres pièces. Dans la suite de la description on adoptera la notation P(M, N) pour désigner la série de pièces utilisées par un dispositif M pour réaliser un paiement auprès d'un dispositif N. Par exemple, selon cette notation, la série de pièces électroniques P(C, IP) est une série de pièces utilisées par le dispositif client C pour réaliser un paiement auprès du dispositif intermédiaire IP. Au cours de l'étape E100, émanant du dispositif client C, le dispositif 10 intermédiaire IP reçoit une requête RAT d'autorisation de transaction comportant: - l'adresse S du dispositif serveur S - l'identificateur I de l'image I à obtenir; - un montant de paiement MP; et 15 - au moins une pièce Pj (C, IP) appartenant à l'ensemble des pièces P(C, IP) utilisables par le dispositif client C pour réaliser un paiement auprès du dispositif intermédiaire IP. Dans le mode de réalisation basé sur le système de paiement PayWord, cette au moins une pièce électronique Pj(C, IP) est telle que toutes les 20 pièces d'indice strictement inférieur à j de l'ensemble de pièces P(C, IP) ont déjà été validées pour des paiements antérieurs par le dispositif intermédiaire IP. L'étape E100 est suivie d'une étape E105 au cours de laquelle le dispositif intermédiaire extrait de la requête RAT le paiement. L'étape El05 est ensuite suivie d'une étape E110 au cours de laquelle le dispositif intermédiaire 25 extrait la référence I de l'image I. Si aucune référence d'image I n'est présente dans la requête RAT ou si le paiement est invalide (les pièces reçues n'appartiennent pas à l'ensemble des pièces P( C, IP)), test E115 négatif le dispositif intermédiaire IP traite la requête d'une façon similaire à celle décrite en référence à la figure 1, à savoir le 30 dispositif intermédiaire IP notifie le dispositif client C d'une erreur (étape E120). Le traitement de ce message d'erreur est décrit plus en détail ci-après en référence à la figure 3. il En présence d'un paiement et d'une référence image, le dispositif intermédiaire vérifie si le paiement est valide. En réponse à un paiement valide (test E115 positif), le dispositif intermédiaire IP vérifie s'il connaît l'image demandée (étape E125). En cas de vérification positive, c'est à dire en présence, dans la table TC, d'une ligne correspondant à l'image, le dispositif intermédiaire met à jour (étape E130) la fréquence de demande FD de l'image I, en ajoutant 1 dans la deuxième colonne de la ligne correspondant à l'image I. En cas de vérification négative, c'est à dire en l'absence, dans la table 10 TC, d'une ligne correspondant à l'image 1, le dispositif intermédiaire crée une nouvelle ligne pour cette image dans la table TC (étape E135). Cette nouvelle ligne contient la référence ID de l'image et une fréquence de demande FD de valeur égale à 1. A ce stade, les rubriques correspondant aux prix PX, durée de validité 15 VL et image I ne sont pas encore renseignées. Ensuite (étape E140), le dispositif intermédiaire IP vérifie si l'image I est dans un emplacement substitut de la table TC. En pratique, le dispositif intermédiaire IP vérifie si la cinquième colonne de la ligne correspondant à l'image contient des données. En outre, si l'image est en cache, l'intermédiaire vérifie si le contenu du cache est toujours valide. Si au moins l'une de ces vérifications donne un résultat négatif, le dispositif intermédiaire vérifie (étape E145) si la fréquence de demande FD de l'image est supérieure ou égale à une fréquence minimale, fmin, prédéfinie. Le test E145 est ici un exemple de vérification d'une condition clef pour la livraison de l'image I à partir de l'emplacement substitut de la table TC. Si la fréquence FD est inférieure à la fréquence minimale fmin, le dispositif intermédiaire IP renvoie au dispositif client (étape E150) une réponse signifiant que le paiement a été accepté. Le traitement de cette réponse est 30 décrit plus en détail ci-après en référence à la figure 4. Si au contraire la fréquence de demande FD de l'image est supérieure à la fréquence minimale, le dispositif intermédiaire IP télécharge l'image I et le prix correspondant PX depuis le dispositif serveur (étape E155). Le dispositif intermédiaire IP vérifie si le téléchargement réussi (étape E160). En pratique, le dispositif intermédiaire vérifie si l'emplacement substitut de la table TC correspondant contient l'image ainsi téléchargée. En cas d'échec dans le téléchargement (étape E165), le dispositif 5 intermédiaire renvoie au client C une réponse signifiant que le paiement a été accepté. Le traitement de cette réponse est décrit plus en détail ci-après en référence à la figure 4. Si l'image est dans la table TC (étape E140), ou si le téléchargement de l'image s'est bien déroulé (étape E160), le dispositif intermédiaire obtient le 10 prix PX de l'image à partir de la table TC (étape E170). Le dispositif intermédiaire IP vérifie alors si le paiement réalisé par le client est correct, c'est-à-dire supérieur ou égal au prix PX de l'image (étape E175). Cette vérification est un autre exemple de vérification d'une condition clef pour la livraison de l'image à partir de la table TC. En cas de comparaison négative, le dispositif intermédiaire IP retourne un message d'erreur (étape E180) dont le traitement est décrit en détail en référence à la figure 3. En cas de comparaison positive, le dispositif intermédiaire IP retourne l'image I (étape El 85) à destination du dispositif client C. En pratique, outre l'image I et le prix PX, le dispositif intermédiaire IP télécharge aussi la durée de validité de l'image. La durée de validité peut être indiquée dans des champs réservés à cette utilisation dans le protocole utilisé pour transmettre l'image. Par exemple, le protocole HTTP propose un en-tête nommé 25 " Expires " indiquant la date limite de validité du contenu de la requête. Un dispositif serveur S peut refuser que les images qu'il vend soient conservées dans des caches, soit pour des raisons techniques (un graphique en temps réel de la bourse, une image d'une camera de type web- cam, ...), soit pour des raisons commerciales (le dispositif serveur ne fait pas confiance au 30 dispositif intermédiaire, ou veut récupérer des informations de la part de chaque dispositif client). Dans ce cas, lors du téléchargement de l'image, le dispositif serveur indique un tel refus de téléchargement au dispositif intermédiaire (via par exemple le protocole utilisé) et le test E160 devient négatif. En pratique, le dispositif serveur S ne fournit une image que contre 5 paiement ou contre justificatif de paiement de la part d'un dispositif intermédiaire. Or, le dispositif intermédiaire IP peut ne pas souhaiter payer pour pouvoir effectuer le service de cache. Une première solution est de mettre en place une procédure spéciale de téléchargement dans laquelle le dispositif intermédiaire IP envoie un 10 justificatif de paiement indiquant qu'il agit en tant qu'intermédiaire de cache. Le dispositif serveur S sait alors qu'il peut renvoyer l'image, mais qu'il ne doit pas attendre de paiement en retour. Cette information peut être utile lorsque le dispositif serveur souhaite tenir une comptabilité des demandes auxquelles il répond et qui génèrent un paiement pour lui. Une deuxième solution consiste pour le dispositif intermédiaire à payer effectivement le dispositif serveur. En contrepartie, le dispositif intermédiaire ne reverse pas au dispositif serveur la somme versée par le dispositif client pour lequel le processus de la figure 2 est en cours d'exécution. Cette seconde solution a l'avantage d'être transparente pour le 20 dispositif serveur qui n'a pas à gérer un traitement particulier pour les dispositifs intermédiaires. Par contre, le dispositif intermédiaire doit réaliser cette opération avec prudence pour être sûr de rentrer dans ses frais. Par exemple, avant depayer le dispositif serveur, le dispositif intermédiaire s'assure que le dispositif client lui a 25 versé un paiement correct et complet. La figure 3 décrit le processus retournant un message d'erreur à un dispositif client C (étape E200). Le dispositif intermédiaire crée une réponse E210, puis ajoute un message d'erreur dans cette réponse E220. Ce message d'erreur indique la raison de l'erreur. Si le dispositif client a effectué un paiement valide (test E230), le dispositif intermédiaire génère un remboursement (E240) et l'inclus dans la réponse (E250). Par exemple, le remboursement du dispositif client est réalisé au moyen des pièces électroniques P(IP,C), le paiement ayant été encaissé par le dispositif intermédiaire au préalable. Ce cas de figure peut aussi se produire lors de l'étape E175 en présence d'un paiement valide, mais insuffisant. La réponse ainsi engendrée est envoyée par le dispositif intermédiaire IP à destination du dispositif client C (E260). La figure 4 décrit le processus selon lequel le dispositif intermédiaire retourne une réponse au dispositif client (étape E300) en présence d'un paiement valide et en l'absence d'une livraison de l'image à partir du cache. Lors de l'étape E310, le dispositif intermédiaire crée une réponse en réplique à une situation dans laquelle le paiement est valide et dans laquelle le dispositif intermédiaire ne joue pas le rôle de cache. Lors de l'étape E320, un message est ajouté dans la réponse ainsi créée pour signifier que le paiement est correct et que le dispositif client C peut 15 télécharger l'image depuis le dispositif serveur S au lieu de faire appel au cache du dispositif intermédiaire. Lors de l'étape E330, le dispositif intermédiaire IP envoie la réponse ainsi construite au dispositif client C. Ensuite (étape E340), le dispositif intermédiaire IP extrait une 20 information identifiant le dispositif client dans la requête RAT envoyée par le client. Cette information peut par exemple être l'adresse de courrier électronique du client. Le dispositif intermédiaire IP crée ensuite une autorisation pour ce client C, avec le prix payé et l'image demandée (étape E350) et mémorise cette 25 information dans une table créée à cet effet (étape E360). Cette autorisation permet de répondre positivement à la requête éventuelle du dispositif serveur demandant si le paiement a bien été effectué par le dispositif client. La table d'autorisation peut avoir la forme suivante 30 Client Prix payé Image demandée C 5 ID La première colonne contient l'identifiant du client C. La deuxième colonne contient le prix payé pour la livraison de l'image. La troisième colonne contient l'identifiant de l'image ainsi payée. La figure 5 décrit le processus permettant de retourner une image en provenance de la table TC du dispositif intermédiaire et à destination du dispositif client C (étape E400). Lors de l'étape E410, le dispositif intermédiaire IP commence par encaisser le paiement. Par exemple, l'encaissement met en place le système de paiement du type PayWord mentionné ci-avant. Ensuite (étape E420), le dispositif intermédiaire IP crée une réponse, y ajoute l'image I obtenue depuis la table TC (étape E430) et enfin retourne la réponse contenant l'image au dispositif client (étape E440). La figure 6 décrit le processus de mise à jour de la table TC (étape E500) Ce processus permet d'enlever de la table TC les images qui ne sont plus nécessaires, afin de limiter la taille de la table TC. Par exemple, ce processus est exécuté régulièrement à intervalles 20 prédéfinis (par exemple tous les jours ou toutes les semaines). Lors de l'étape E505, le dispositif intermédiaire commence par obtenir l'identifiant ID d'une image I pour laquelle existe une ligne dans la table TC. Lors de l'étape E510, le dispositif intermédiaire applique un facteur d'oubli à la fréquence. Par exemple, l'étape E510 consiste à multiplier la fréquence de demande FD associée à l'image par un nombre inférieur à 1. Ainsi, en utilisant un facteur de 0,5, deux demandes dans la période précédente comptent autant qu'une demande dans la période courante. Ensuite la nouvelle valeur de la fréquence FD de l'image est 30 comparée à une fréquence prédéfinie frem dite de "mise à jour" (étape E515). Si la fréquence de l'image FD est inférieure à la fréquence frem, alors l'image ne sera pas conservée dans la table TC. Dans ce cas (l'étape E520), l'image est enlevée de la cinquième colonne de la table TC formant cache. Seules les données correspondant à l'image, son prix et sa durée de validité sont enlevées de la table TC. En revanche, l'identifiant ID et la fréquence de demande FD de l'image sont conservées dans la table TC. Puis, la nouvelle valeur de la fréquence de l'image FD est comparée à une autre fréquence prédéfinie dite de "suppression" fdel (étape E525). Si la fréquence de l'image FD est inférieure à la fréquence de suppression fdel, alors à l'étape E530, toutes les données (notamment identifiant ID et fréquence FD) 10 de la ligne correspondant à l'image sont enlevées de la table TC. Le processus se répète selon une boucle (étapes E535, E540) jusqu'au traitement de la dernière image contenue dans la table TC (étape E545). Le choix des fréquences frem et fdel détermine le bon fonctionnement 15 du mécanisme. Si la fréquence de "mise à jour" frem est égale à la fréquence minimale fmin, la même limite est utilisée pour mettre une image dans le cache ou pour l'enlever. Cependant, dans certaines configurations, cela peut conduire à continuellement ajouter et enlever une image de la table TC, car la fréquence 20 de demande de cette image est proche de la fréquence fmin. Pour résoudre ce problème, il est possible de choisir la fréquence frem inférieure strictement à la fréquence fmin. On obtient ainsi un principe d'Hystérésis pour mettre l'image en cache, il faut que la fréquence passe une certaine limite, mais pour l'enlever, il faut que la fréquence redescende bien en dessous de cette limite. Si la fréquence de "suppression" fdel est inférieure à la fréquence de "mise à jour" frem, la fréquence de suppression correspond à une valeur indiquant que l'image n'a pas été demandée depuis plusieurs périodes et qu'il n'est donc pas utile de conserver des informations par rapport à cette image. Une variante de ce système consiste à compter le nombre de 30 demandes pour une image pour chaque période. Ainsi, pour chaque image, il existe une table de comptage contenant les nombres de demandes pour chaque période. Par exemple, la table de comptage à la structure suivante: 34... 54 34 La colonne Wn correspond à la période la plus ancienne conservée, la colonne W0 correspond à la période courante. Lors de la mise à jour, la valeur de la colonne Wn est oubliée, tandis 5 que les valeurs des autres colonnes sont décalées vers la gauche. La valeur de En pratique, les tests s'effectuent par rapport aux fréquences prédéfinies fmin, frem et fdel. La fréquence de l'image FD est recalculée à partir de ce tableau de comptage. Un coefficient est appliqué à chaque colonne, le 10 coefficient de chaque colonne étant inférieur ou égal au coefficient de la colonne à sa droite (ainsi, le coefficient de Wn est inférieur ou égal à celui de Wn-1, ...). Une telle variante permet de tenir compte des demandes par rapport à des périodes, par exemple hebdomadaires ou journalières, afin d'entretenir la table TC et supprimer le cas échéant les images relativement peu demandées. Une autre variante consiste à utiliser une information relative à la bande passante b (ou débit) du dispositif serveur, cette information étant susceptible d'être mémorisée dans la table TC. Par exemple, cette information est récupérée régulièrement par le dispositif intermédiaire IP par un processus approprié (par exemple détection de 20 la bande passante b, vérification de la valeur ainsi détectée par rapport à un seuil et stockage en cas de vérification positive). Ainsi, pour chaque image dont la fréquence de demande FD est supérieure à une valeur prédéterminée, le dispositif intermédiaire IP teste la capacité de réponse du dispositif serveur S en lui envoyant un message de test. 25 Ce test permet de fournir au dispositif intermédiaire une valeur b indiquant la taille de la bande passante du dispositif serveur. Plus la bande passante est importante, plus cette valeur b est importante. Par exemple, les tests pour mettre une image dans les emplacements substituts du cache ou l'enlever dudit cache, peuvent alors prendre en compte 30 cette valeur b, par exemple en comparant FD/b à la fréquence fmin ou à la fréquence frem conformément aux étapes décrites en référence à la figure 2. Cette comparaison est un autre exemple de condition clef pour la livraison d'un fichier de données à partir d'un emplacement substitut. Ainsi, le dispositif intermédiaire IP aura tendance à mettre en cache plus facilement une image fournie par un dispositif serveur ayant une capacité 5 faible à répondre à une demande importante qu'une autre image fournie par un dispositif serveur ayant une grande capacité à répondre à une demande importante. De manière similaire, une autre variante consiste à utiliser une information relative à la disponibilité du dispositif serveur. Au lieu de mesurer la 10 bande passante du serveur, le dispositif intermédiaire IP vérifie régulièrement si le dispositif serveur répond à ses requêtes et avec quelle rapidité il répond aux requêtes (ce mécanisme reprend le principe de la commande " ping " qui teste la disponibilité d'un ordinateur dans un réseau). Cette variante est encore un autre exemple de condition clef pour la 15 livraison d'un fichier de données à partir d'un emplacement substitut. La figure 7 représente schématiquement un dispositif intermédiaire de paiement adapté à mettre un oeuvre un procédé de traitement conforme à la présente invention, dans un mode préféré de réalisation. Ce dispositif intermédiaire de traitement peut notamment être 20 constitué par un ordinateur. Dans l'exemple de réalisation décrit ici, le dispositif intermédiaire de paiement comporte une carte de communication 807 pour relier le dispositif intermédiaire à un réseau de communication, un clavier 810, un écran 809, reliés à un port d'entrées-sorties 803 d'une carte de traitement 801. La carte de traitement 801 comporte, reliés entre eux par un bus d'adresses et de données 802: - une unité centrale de traitement 800 - une mémoire vive RAM 804; - une mémoire morte ROM 805; - une mémoire non volatile FLASH 806 et - le port d'entrées-sorties 803. Chacun des éléments illustrés en figure 7 est bien connu de l'homme du métier des micro-ordinateurs et, plus généralement, des systèmes de traitement de l'information. Ces éléments communs ne sont donc pas décrits ici. La mémoire vive 804 comporte notamment: - un registre REQUETE pour mémoriser tout type de requête reçue en provenance du dispositif client C ou du dispositif serveur S, à savoir en particulier, une requête RAT d'autorisation de transaction, et une requête RAL d'autorisation de livraison; - un registre MESSAGE pour mémoriser, préalablement à leur envoi, 10 les messages destinés au dispositif client C et au dispositif serveur S et notamment les messages MVT de validité de la transaction et d'accusé réception du paiement OKI. La mémoire non volatile FLASH 806 comporte des registres pour mémoriser, conformément au système de paiement PayWord, la pièce racine P0 15 et la dernière pièce valablement reçue ou émise Pi, pour les séries de pièces P(C, IP), P(IP, C) et P(IP, S), respectivement utilisées pour: - les paiements effectués par le dispositif client C au profit du dispositif intermédiaire IP; - les remboursements effectués par le dispositif intermédiaire IP au 20 profit du dispositif client C en cas d'annulation de la transaction; et - les paiements effectués par le dispositif intermédiaire IP au profit du dispositif serveur S en cas de validation de la transaction. La mémoire morte 805 est adaptée à conserver le programme de fonctionnement de l'unité centrale de traitement 800. Elle comporte notamment 25 un registre "Program" pour mémoriser les instructions d'un programme mettant en oeuvre un procédé de traitement conforme à l'invention, tel que décrit précédemment en référence aux organigrammes des figures 2 à 6. Par exemple, la table de correspondance TC, la table de comptage et la table d'autorisation sont stockées dans la mémoire RAM de l'ordinateur. Ces 30 tables peuvent être stockées dans tout autre moyen de stockage du dispositif intermédiaire. Le dispositif de traitement comporte des moyens de communication classiques connus de l'homme du métier, adaptés à communiquer, au moyen de requêtes et de messages avec d'autres dispositifs du réseau de communication. Ces moyens de communication sont en particulier constitués par la 5 carte de communication 807 et des portions de code informatique mémorisées dans la mémoire morte ROM 805 mettant en oeuvre des couches protocolaires classiques telles que TCP/IP par exemple. Quoiqu'il en soit ces moyens de communication constituent des moyens de réception adaptés à recevoir et/ou envoyer les requêtes et/ou 10 messages RAT, RAL, OK, et MVT. Les moyens de communication sont en particulier adaptés à reconnaître le type d'une requête reçue et à en extraire les différents champs. REVENDICATIONS 1. Procédé de traitement d'une transaction électronique entre un dispositif client 5 (C) et un dispositif serveur (S) sur un réseau de communication, ledit procédé de traitement étant mis en oeuvre au sein d'un dispositif intermédiaire (IP) du réseau de communication servant d'intermédiaire de paiement pour ladite transaction, caractérisé en ce qu'il comprend les étapes suivantes: - en provenance du dispositif client (C), recevoir une requête de 10 livraison (RAT) d'un fichier de données (1) ayant une désignation choisie (ID); - obtenir une table de correspondance (TC) entre une désignation d'un fichier de données (ID), au moins un emplacement substitut de celui-ci, et au moins une condition clef pour la livraison du fichier de données à partir de l'un des emplacements substituts - vérifier si au moins l'une des conditions clefs obtenues est vraie, et en cas de vérification positive, livrer à destination du dispositif client (C) le fichier de données (1) à partir de l'un des emplacements substituts. 2. Procédé selon la revendication 1, dans lequel la requête (RAT) est en outre 20 accompagnée d'un montant de paiement (MP) correspondant à la livraison, caractérisé en ce que le procédé comprend en outre l'étape dans laquelle il est prévu d'établir la correspondance avec un prix associé à la livraison (PX) dudit fichier de données, de comparer le montant du paiement (MP) ainsi reçu avec le prix (PX) de livraison, et en cas de comparaison négative de ne pas livrer le 25 fichier de données (1) à partir de l'un des emplacements substituts. 3. Procédé de traitement selon la revendication 1 ou la revendication 2, caractérisé en ce qu'au moins une condition clef est définie en fonction de la fréquence des demandes, de l'obsolescence et/ou d'une caractéristique de 30 chaque fichier de données à livrer. 4. Procédé de traitement selon l'une des revendications 1 à 3, caractérisé en ce qu'au moins une condition clef est définie en fonction d'au moins une caractéristique du dispositif serveur. 5. Procédé de traitement selon la revendication 4, caractérisé en ce qu' au moins une caractéristique du dispositif serveur participant à la définition d'une condition clef est la disponibilité du serveur et/ou la bande passante (b) du serveur. 6. Procédé selon l'une des revendications 1 à 5, dans lequel toutes les 10 conditions clefs obtenues doivent être vérifiées positivement pour que le fichier de données (1) soit livré à partir de l'un des emplacements substituts 7. Procédé de traitement selon l'une des revendications 1 à 6, caractérisé en ce que la table de correspondance (TC) comprend au moins deux emplacements 15 substituts ayant respectivement au moins une condition clef associée et en ce qu'au moins une condition clef associée à un emplacement substitut n'est pas associé à au moins un emplacement substitut différent. 8. Procédé de traitement selon l'une des revendications 1 à 7, caractérisé en ce 20 qu'il est prévu d'entretenir et/ou mettre à jour la table de correspondance (TC) en fonction de la fréquence des demandes, de l'obsolescence et/ou d'une caractéristique de chaque fichier de données à livrer ou en fonction de la disponibilité et/ou de la bande passante (b) du serveur. 9. Dispositif de traitement d'une transaction électronique entre un dispositif client (C) et un dispositif serveur (S) sur un réseau de communication, ledit dispositif de traitement étant susceptible d'être incorporé dans un dispositif intermédiaire (IP) du réseau de communication et caractérisé en ce qu'il comporte: - des moyens de réception d'une requête (RAT) de livraison d'un 30 fichier de données ayant une désignation choisie (ID); - une table de correspondance (TC) représentative d'une correspondance entre une désignation (ID) d'un fichier de données (1), au moins un emplacement substitut de celui-ci, et au moins une condition clef pour la livraison du fichier de données à partir de l'un de ces emplacements substituts et - des moyens de traitement aptes à accéder à la table (TC), à vérifier si au moins l'une des conditions clefs pour la livraison du fichier de données 5 associée audit fichier ainsi désigné est vraie et en cas de vérification positive, à livrer à destination du dispositif client le fichier de données à partir de l'un de ces emplacements substituts. 10. Dispositif de traitement selon la revendication 9, caractérisé en ce que ladite 10 table de correspondance (TC) comprend en outre une indication relative au prix (PX) associé à la livraison dudit fichier de données, en ce que les moyens de réception sont aptes à recevoir une requête (RAT) accompagnée d'un montant de paiement (MP) correspondant à la livraison, et en ce que les moyens de traitement sont aptes à comparer le montant du paiement (MP) ainsi reçu avec le 15 prix (PX) de livraison, et en cas de comparaison négative à ne pas livrer le fichier de données (1) à partir de l'emplacement substitut. 11. Dispositif de traitement selon la revendication 9 ou la revendication 10, caractérisé en ce qu'au moins une condition clef est définie en fonction de la 20 fréquence des demandes (FD), de l'obsolescence et/ou d'une caractéristique de chaque fichier de données à livrer. 12. Dispositif de traitement selon l'une des revendications 9 à 11, caractérisé en ce qu'au moins une caractéristique du dispositif serveur participant à la définition 25 d'une condition clef est la disponibilité du serveur et/ou la bande passante (b) du serveur. 13. Dispositif de traitement selon la revendication 12, caractérisé en ce que les moyens de traitement comprennent des moyens de détection aptes à détecter la 30 bande passante (b) du dispositif serveur (S). 14. Dispositif de traitement selon l'une des revendications 9 à 13, dans lequel toutes les conditions clefs obtenues doivent être vérifiées positivement pour que le fichier de données (1) soit livré à partir de l'un des emplacements substituts. 15. Dispositif selon l'une des revendications 9 à 14, caractérisé en ce que la table de correspondance (TC) comprend au moins deux emplacements substituts ayant respectivement au moins une condition clef associée et en ce qu'au moins une condition clef associée à un emplacement substitut n'est pas associé à au moins un emplacement substitut distinct. 10 16. Dispositif de traitement selon l'une des revendications 9 à 15, caractérisé en ce que les moyens de traitement comprennent des moyens d'entretien et/ou de mise à jour de la table de correspondance (TC) en fonction de la fréquence des demandes, de l'obsolescence et/ou d'une caractéristique de chaque fichier de 15 données à livrer ou en fonction de la disponibilité et/ou de la bande passante (b) du serveur. 17. Dispositif de traitement selon l'une des revendications 9 à 16, caractérisé en ce que les moyens de traitement comprennent des moyens de remplissage 20 aptes à télécharger le fichier de données à livrer (1) à partir du dispositif serveur (S) et à destination de l'un des emplacements substituts correspondant. 18. Dispositif intermédiaire caractérisé en ce qu'il comporte des moyens adaptés à mettre en oeuvre un procédé de traitement selon l'une quelconque des 25 revendications 1 à 8. 19. Dispositif intermédiaire caractérisé en ce qu'il comporte un dispositif de traitement selon l'une quelconque des revendications 9 à 17. 20. Système de transaction électronique dans un réseau de communication caractérisé en ce qu'il comporte un dispositif intermédiaire selon la revendication 18 ou la revendication 19. 21. Support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions 5 d'un programme d'ordinateur permettant la mise en oeuvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 8, lorsque ce programme est chargé et exécuté par un système informatique. 22. Programme d'ordinateur stocké sur un support d'informations, ledit 10 programme comportant des instructions permettant la mise en oeuvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 8, lorsque ce programme est chargé et exécuté par un système informatique.