Brevet FR2858893A1 — publié le 20050218

Procédé et programme informatique pour estimer la qualité d'un échange de données via un réseau distant L'invention concerne l'estimation de la qualité d'un 5 service en ligne, en particulier la qualité d'un échange de données via un réseau étendu, notamment le réseau Internet. Lorsque des données sont transmises, généralement sous forme de paquets de données (notamment des paquets IP pour "Internet Protocole"), d'une première entité vers une seconde entité, il advient que les données reçues soient au moins partiellement erronées, ou que les données envoyées soient au moins partiellement perdues, ou encore que la transmission des données soit retardée par une congestion momentanée du réseau étendu ou par une surcharge d'une entité intermédiaire qui assure le transit des données dans le réseau étendu. Lorsque les première et seconde entités précitées sont respectivement une entité client et une entité fournisseur telle qu'un fournisseur de service en ligne ou de services WEB à un ou plusieurs clients privilégiés, on comprendra qu'il doit être tenu compte, dans la prestation du fournisseur, de la qualité de l'échange de données, notamment en terme de temps de transit des échanges de données, de taux d'erreurs ou de perte dans les données reçues ou envoyées, ou autres. Ces paramètres définissant ainsi une qualité de l'échange des données peuvent être obtenus, notamment par implémentation d'applications logicielles connues telles que: - "PING" pour évaluer la durée de transit entre une première et une seconde entité, avec un taux d'erreurs 5 dans les données transitées, - "TRACEROUTE" pour lister une ou plusieurs entités intermédiaires assurant le routage des données via le réseau entre les première et seconde entités, et/ou - des programmes d'analyse de codes d'erreur dans les données échangées. De telles applications permettent d'obtenir les paramètres précités, relatifs à la qualité de l'échange de données. Toutefois, elles ne peuvent être implémentées qu'au coup par coup, sur demande d'un utilisateur de l'une des première et seconde entités. Ainsi, si une entité client constate un dysfonctionnement épisodique dans l'échange de données, cette entité client peut difficilement apporter la preuve de ce dysfonctionnement à son fournisseur. En outre, de manière plus générale, une entité fournisseur peut rechercher une analyse régulière et systématique de la qualité de ses échanges de données avec des entités clients, le cas échéant pour augmenter cette qualité, notamment en réduisant les durées de transit et/ou de traitement, ou en sélectionnant des entités intermédiaires de routage minimisant le taux d'erreur dans les données reçues, ou autres. Or, les applications logicielles précitées n'assurent pas une telle analyse régulière et systématique. La présente invention vient améliorer la situation. Elle propose à cet effet un procédé pour estimer la 5 qualité d'un échange de données, via un réseau étendu, notamment le réseau Internet, dans lequel: a) on émet, à partir d'une première entité équipée au moins d'un module mémoire, au moins un paquet de données requête, via un réseau étendu, à une seconde entité, b) dès réception du paquet requête par la seconde entité, on réémet un paquet réponse vers la première entité, et c) dès réception du paquet réponse, auprès de la première entité, on stocke dans le module mémoire de la première entité des paramètres relatifs à une qualité d'échange de paquets entre les première et seconde entités, comprenant au moins un temps de transit des paquets via le réseau étendu. Ainsi, en mémorisant les paramètres précités, on garde une trace de l'évaluation de la qualité de l'échange. Par exemple, cette mémorisation peut être effectuée avant une transaction via le réseau étendu, entre la première entité et la seconde entité, pour connaître sensiblement les conditions d'échanges de données au cours d'une future transaction. Toutefois, en variante et dans un mode de réalisation préféré, la première entité émet répétitivement une pluralité de paquets requêtes à différents instants prédéterminés, par exemple régulièrement, pour stocker successivement dans le module mémoire précité les paramètres de qualité. Les données relatives à ces paramètres sont préférentiellement rangées dans le module mémoire en fonction des différents instants précités, avantageusement sous la forme d'un historique et/ou sous la forme de moyennes dans le temps, associées aux paramètres de qualité. Préférentiellement, on tient compte en outre d'une durée de traitement que prend la seconde entité pour au moins interpréter les données du paquet requête qu'elle reçoit. A cet effet, bi) on prévoit un traitement des données du paquet requête, comportant au moins une interprétation desdites données, dès réception du paquet requête par la seconde entité, et cl) dans le module mémoire de la première entité, on stocke en outre, parmi lesdits paramètres, une durée de traitement par la seconde entité comprenant au moins un temps d'interprétation du paquet requête. Avantageusement, pour évaluer aussi la rapidité et les capacités de traitement de la seconde entité, b2) on prévoit en outre une mise en forme de données pour former un paquet réponse, après ladite interprétation des données du paquet requête par la seconde entité, et ladite durée de traitement par la seconde entité comprend alors en outre un temps de mise en forme du paquet réponse. On indique qu'en variante, on peut aussi prévoir d'envoyer des paquets requêtes nécessitant des réponses sous la forme de services en ligne ou de services WEB. Dans cette variante, on évaluera directement la rapidité de la réponse sous la forme du service rendu. Dans une réalisation particulièrement avantageuse, la première entité au moins est équipée en outre d'un système d'exploitation et ce système d'exploitation est agencé pour gérer en tâche de fond l'envoi et la réception des paquets, ainsi que la mémorisation des paramètres dans le module mémoire. Ainsi, le déroulement des étapes a), b) et c) est sensiblement transparent pour un utilisateur mais cet utilisateur peut néanmoins accéder, s'il le souhaite, au contenu du module mémoire à partir de la première entité, ou encore à partir de la seconde entité, comme on le verra ci-après. Dans une réalisation où la première entité est une entité client et la seconde entité est une entité fournisseur de service en ligne, la seconde entité, fournisseur, est agencée pour accéder au contenu du module mémoire de la première entité, client. Ainsi, le fournisseur peut obtenir une estimation de la qualité de son service, et plus particulièrement de la qualité de l'échange des données avec ses clients. On comprendra ainsi que le module mémoire qui stocke les données relatives aux paramètres précités correspond sensiblement à une "sonde" de la qualité de l'échange des données via le réseau étendu. Le procédé au sens de la présente invention étant principalement mis en uvre par des moyens informatiques, la présente invention vise aussi un produit programme d'ordinateur, stocké dans une mémoire d'une installation informatique équipée d'un module de communication via un réseau étendu, ou sur un support destiné à coopérer avec un lecteur de ladite installation, ou encore encodé pour être téléchargé vers ladite installation informatique à partir d'un serveur distant via le réseau étendu. Le programme au sens de l'invention comporte alors des instructions pour mettre en uvre au moins: - les étapes a) et c) du procédé ci-avant, lorsque ces instructions sont chargées dans une mémoire de travail de l'installation informatique si cette 15 installation correspond à la première entité précitée, - et l'étape b) du procédé ci-avant, lorsque ces instructions sont chargées dans une mémoire de travail de l'installation informatique si cette installation correspond à la seconde entité précitée. D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-25 après, et des dessins annexés sur lesquels: - la figure 1 représente de façon générale une communication entre une entité client et une entité fournisseur, via un réseau étendu; la figure 2 représente schématiquement les éléments, par 30 exemple d'une unité centrale, dont la coopération permet de déterminer notamment la durée d'un échange de paquets de données via le réseau étendu; - la figure 3 représente schématiquement l'échange d'un paquet témoin entre l'entité client et l'entité fournisseur; - la figure 4 représente schématiquement les étapes de création d'un paquet requête témoin, d'envoi de ce paquet, de l'entité client à l'entité fournisseur, et de réception d'un paquet de données réponse, renvoyé par l'entité fournisseur, pour déterminer notamment une durée de l'échange de ces paquets entre les entités client et fournisseur; - la figure 5 représente schématiquement un échange de données entre l'entité client et l'entité fournisseur, via une pluralité d'entités intermédiaires dans le réseau étendu précité ; et - la figure 6 représente schématiquement une entité fournisseur EF agissant en tant qu'intermédiaire entre une entité client EC et plusieurs fournisseurs de services FA1, FA2, FA3, dans un mode de réalisation particulier de la présente invention. On se réfère tout d'abord à la figure 1 sur laquelle deux entités informatiques: une entité client EC et une entité fournisseur EF, échangent des données via un réseau étendu 1, par exemple via le réseau Internet. Dans l'exemple décrit, chaque entité se présente simplement sous la forme d'un ordinateur comportant classiquement un écran de visualisation, des organes de saisie tels qu'un clavier et/ou une souris, ainsi qu'une unité centrale portant la référence 2 pour l'entité client EC et la référence 3 pour l'entité fournisseur EF. Bien entendu, l'unité centrale de l'entité client EC comporte un module de communication 22 via le réseau étendu 1, tel qu'un modem par exemple. De la même manière, l'entité fournisseur EF comporte un module de communication 32 via le réseau étendu 1. Avantageusement, l'unité centrale de l'entité client EC comporte un lecteur 21, d'un support amovible stockant un programme au sens de la présente invention, comme un CD-ROM, une disquette, ou tout autre support mémoire. De la même manière, l'unité centrale 3 de l'entité fournisseur EF comporte un lecteur 31 d'un support mémoire amovible tel qu'un CD-ROM, une disquette ou autre. On comprendra que les lecteurs 21 et/ou 31 permettent de charger dans la mémoire morte ROM ou dans la mémoire vive RAM tout ou partie des instructions d'un programme d'ordinateur au sens de la présente invention, ce programme permettant de déterminer la qualité des échanges de données entre les deux entités EC et EF, comme on le verra ci-après. En se référant maintenant à la figure 2, l'unité centrale 2 de l'entité client EC peut comporter, dans l'exemple décrit, une interface de communication 22 (par exemple un modem) avec le réseau étendu 1. L'unité centrale 2 comporte en outre une mémoire de travail (par exemple une mémoire vive) RAM dans laquelle peuvent être chargées des instructions de programme d'ordinateur. Un programme d'ordinateur 23 de codage/décodage permet de mettre en forme les données, par exemple sous forme de paquets IP pour un réseau étendu de type Internet. Pour une réception de paquets, ce module 23 interprète le contenu des paquets reçus et en extrait les données qu'ils contiennent. En variante de la représentation de la figure 2, le module 23 peut être un programme résident dans une mémoire de l'interface de communication 22. L'unité centrale 2 comporte en outre une horloge interne 24 qui, en variante de la représentation de la figure 2, peut être résidente dans le processeur 25. L'unité centrale 2 est équipée en outre d'une mémoire morte ROM, pour notamment stocker des données de façon permanente. La mémoire de travail RAM stocke en particulier des instructions d'un programme d'ordinateur au sens de la présente invention, portant la référence 27 sur la figure 2. Ce programme, dans l'exemple décrit, pilote notamment l'émission d'au moins un paquet requête témoin, à un instant prédéterminé, indiqué par l'horloge interne 24. Comme on le verra ci-après, ce paquet témoin est transmis via le réseau interne 1 à l'entité fournisseur, laquelle renvoie un paquet réponse témoin à l'entité client. Lorsque le paquet témoin revient à l'entité client, le module de codage/décodage 23 reconnaît ce paquet témoin et l'horloge interne 24 indique l'instant de retour du paquet témoin, pour en déduire une durée d'aller/retour du paquet témoin entre l'entité client et l'entité fournisseur. Cette durée est mémorisée sous forme numérique dans la mémoire morte ROM, en particulier dans un module mémoire 26, au sens de la présente invention. Ainsi, on comprendra que le programme informatique 27 permet de commander l'émission du paquet témoin et de déterminer la durée d'aller et retour de ce paquet témoin, ainsi que la mémorisation de cette durée dans le module mémoire 26. On indique que le processeur 25 permet de piloter la coopération entre les différents modules représentés sur la figure 2. On se réfère maintenant à la figure 3 pour décrire plus en détail l'échange d'un paquet témoin entre les entités client EC et fournisseur EF. L'interface de communication 22 de l'entité client émet à un premier instant prédéterminé (fourni par l'horloge interne 24) un paquet requête témoin (flèche PT11) via le réseau étendu 1 et à destination de l'entité fournisseur EF. L'interface de communication 32 de l'entité fournisseur EF reçoit ce paquet requête (flèche PT12). Un module de codage/décodage 33 de l'entité fournisseur EF interprète le paquet requête comme étant un paquet témoin qui doit être renvoyé à l'entité client EC (flèche PT22). A cet égard, on comprendra que la mémoire de travail de l'entité fournisseur peut avantageusement comporter des instructions de programme informatique pour piloter le module de codage/décodage 33 de l'entité fournisseur, de manière à reconnaître un champ identifiant les paquets reçus comme étant des paquets témoins, de sorte qu'ils soient retournés systématiquement à l'entité client EC. Le module de codage/décodage 33 de l'entité fournisseur met en forme un paquet réponse témoin qui est renvoyé par l'entité fournisseur EF et reçu par l'interface de communication 22 de l'entité client EC (flèche PT21), à un second instant prédéterminé (fourni par l'horloge interne 24). Le processeur 25 de l'unité centrale 2 de l'entité client EC calcule, sur commande des instructions du programme 27, un écart entre le premier et le second instant prédéterminé définissant donc une durée: - d'aller du paquet requête vers l'entité fournisseur, - traitement du paquet requête par l'entité fournisseur, - mise en forme du paquet réponse, et - retour du paquet réponse vers l'entité client. Cette durée est mémorisée dans le module mémoire 26. Plus précisément, le paquet requête témoin, lui-même, comporte dans un champ de données particulier, un identifiant de l'entité client EC (par exemple une adresse IP), ainsi que des données d'instructions (par exemple sous forme de code) pour réémettre le paquet témoin sous la forme d'un paquet réponse de l'entité fournisseur EF à l'entité client EC, l'entité client EC étant déterminée par l'identifiant précité dans le paquet témoin. Dans une réalisation particulièrement avantageuse, l'entité client EC émet une pluralité de paquets témoins à différents instants prédéterminés, de manière à stocker dans le module mémoire 26 des durées d'aller, traitement et retour de chaque paquet témoin, successivement. Ces durées peuvent être stockées en correspondance d'une heure et d'une date précises d'émission/réception, de manière à retrouver dans le module mémoire 26 un historique de la qualité des échanges, en terme de durée d'échange des données entre les entités EC et EF. En complément ou en variante, le module de mémoire 26 peut stocker une durée, moyennée sur les différents instants d'émission. On comprendra ainsi que cette durée moyenne est un paramètre représentatif de la qualité des échanges de données entre les deux entités. Typiquement, si l'entité client peut communiquer avec une pluralité d'entités fournisseur, le module mémoire 26 peut stocker une durée moyenne pour chaque entité fournisseur et un utilisateur d'une entité client pourra déterminer la meilleure qualité d'échanges qu'offre l'une des entités fournisseurs. Ainsi, le meilleur fournisseur, par rapport à ce critère, est celui dont la durée moyenne des échanges est la plus faible. Par ailleurs, il peut advenir que la durée des échanges soit variable au cours du temps, notamment en fonction de la surcharge de l'entité fournisseur et/ou de la congestion du réseau étendu. Dans le contexte d'une transaction entre l'entité client et l'entité fournisseur, l'historique précité, mémorisé dans le module mémoire 26, pourra déterminer si cette transaction a par exemple été retardée à cause d'un problème matériel lié à l'entité fournisseur ou plutôt à cause d'une congestion du réseau. Préférentiellement, les paquets requêtes sont émis régulièrement, de manière à obtenir un historique efficace de la qualité des échanges. Par exemple, des paquets témoins peuvent être émis toutes les quinze minutes. De façon avantageuse, le programme informatique 27, au sens de la présente invention, opère en tâche de fond dans un système d'exploitation (par exemple MICROSOFT WINDOWS ) dont est équipé l'entité client EC, de manière à ne pas perturber le déroulement d'applications en cours que gère ce système d'exploitation. On se réfère maintenant à la figure 4 pour détailler les étapes a), b) et c) du procédé au sens de la présente invention. Tout d'abord, on comprendra que les étapes a) et c) sont implémentées auprès de l'entité client EC, tandis que l'étape b) est implémentée auprès de l'entité fournisseur EF. L'étape a) commence par une opération 41 consistant à repérer un instant prédéterminé que fournit l'horloge interne de l'unité centrale 2 de l'entité client pour envoyer, à cet instant, un paquet témoin (opération 42) mis en forme et transmis par l'interface de communication (opération 43) au réseau étendu précité. Ce paquet est routé, dans le réseau étendu (opération 44) vers l'entité fournisseur EF qui reçoit donc le paquet témoin (opération 45) par son interface de communication. Le module de codage/décodage de l'entité fournisseur traite ce paquet (opération 50) et reconnaît en particulier dans le paquet témoin les données d'instructions de réémission de ce paquet témoin vers l'entité client (opération 46) et l'entité fournisseur renvoie le paquet témoin, à nouveau via le réseau étendu (opération 47). Dès réception du paquet témoin par l'entité client, l'horloge interne de l'entité client donne l'instant de réception du paquet témoin (opération 48) et, de là, la durée d'aller/retour du paquet témoin, laquelle est mémorisée dans le module mémoire (opération 49). On répète régulièrement ces opérations pour obtenir l'historique et/ou la durée moyenne déterminant ainsi l'un des paramètres de la qualité des échanges de données entre l'entité client et l'entité fournisseur, comme indiqué ci- avant. On comprendra ainsi que le programme d'ordinateur au sens de la présente invention peut comporter deux versions, l'une destinée à être implémentée dans l'unité centrale de l'entité client (pour la mise en uvre des étapes a) et c)) et l'autre destinée à être implémentée dans l'unité centrale de l'entité fournisseur (pour la mise en uvre de l'étape b) du procédé au sens de la présente invention). Avantageusement, le module mémoire 26 stocke en outre une information relative à un taux d'erreur dans les paquets échangés entre l'entité client et l'entité fournisseur. On indique qu'à cet effet, une application logicielle de type TRACEROUTE peut être utilisée mais on comprendra, bien entendu, que le résultat que fournit cette application est stockée dans le module mémoire, régulièrement, si une pluralité de paquets témoins sont successivement échangés, selon le procédé au sens de la présente invention. Ainsi, le contenu du module mémoire 26 donne des informations objectives quant à la qualité du service WEB que fournit l'entité fournisseur EF à l'entité client EC. A ce titre, le module mémoire 26, de par son contenu, agit comme une "sonde" de la qualité du service WEB rendu. Les paramètres objectifs stockés dans ce module mémoire sont donc difficilement contestables par l'une ou l'autre des entité client et entité fournisseur. On se réfère maintenant à la figure 5 sur laquelle les données échangées entre l'entité client EC et l'entité fournisseur EF transitent via une pluralité d'entités intermédiaires du réseau étendu 1, ces entités intermédiaires correspondant, dans l'exemple décrit: - à un fournisseur d'accès FC de l'entité client EC, - à une ou plusieurs entités de routage RA, RB, RC, et - à un fournisseur d'accès FF de l'entité fournisseur EF. Sur la figure 5, les entités de routage par lesquelles ne transitent pas les données échangées entre les entités client EC et fournisseur EF portent la référence RO. On comprendra ainsi que le logiciel TRACEROUTE permet de déterminer, pour chaque entité intermédiaire, une durée de transit et/ou un taux d'erreur dans les paquets échangés. Selon l'invention, ces informations sont stockées sous la forme d'un historique ou d'une moyenne pour chaque entité intermédiaire dans le module mémoire 26. On indique en outre que les informations d'erreur qui sont générées pendant l'émission/réception d'un paquet témoin peuvent être des messages d'erreur de type "SOAP" et sont stockées aussi dans le module mémoire 26. On se réfère maintenant à la figure 6 pour décrire un exemple de réalisation, selon une variante du mode de réalisation représenté sur la figure 5. Dans cette variante, l'entité fournisseur EF agit maintenant en tant qu'entité intermédiaire et a recours, elle-même, à d'autres entités fournisseur FAl, FA2, FA3, SER. Dans le schéma représenté, les entités FAl, FA2, FA3 fournissent donc, elles-mêmes, des services WEB, tandis que l'entité SER peut être un serveur distant, fournissant par exemple des informations extraites d'une base de données, ou autre. Dans ce contexte d'intermédiation, l'entité fournisseur EF porte préférentiellement ellemême le module mémoire 26 en tant que "sonde". En consultant ce module 26, elle peut connaître la meilleure qualité d'échange de données que procure l'un des fournisseurs de service WEB FA1, FA2, FA3, ou encore le serveur distant SER. De manière générale, on indique qu'un service WEB (de l'anglais "WEB service") consiste en un dialogue entre deux entités via des requêtes et des réponses à travers un réseau étendu. Par exemple, un serveur sur lequel est installé des applications telles que APACHE Axi5TM couplées à des applications TOMCATTM offre des services WEB en hébergeant des pages HTML ou autres fichiers en tant que "services" téléchargeables. L'entité client émet alors vers le serveur une requête de téléchargement comportant par exemple les informations demandées, des paramètres d'échange de données qui sont à respecter, ou autres. Ainsi, la présente invention trouve une application avantageuse à l'estimation de la qualité d'un service WEB, notamment en terme: - de durée d'exécution du service, - de validité des données transmises (notamment par une analyse de codes d'erreur), et - de disponibilité de l'entité fournisseur (notamment par une estimation de la durée de traitement des paquets requêtes). Bien entendu, la présente invention ne se limite pas à la forme de réalisation décrite ci-avant à titre d'exemples; elle s'étend à d'autres variantes. Ainsi, on comprendra que les termes "première" et "seconde" entités désignent respectivement, dans un mode de réalisation préféré, l'entité client et l'entité fournisseur, décrites ci-avant. En variante, il peut être prévu que les étapes a) et c) soient mises en oeuvre plutôt par l'entité fournisseur EF, tandis que l'étape b) est mise en uvre par l'entité client EC. Dans cette variante, le module mémoire stockant les paramètres définissant la qualité des échanges de données est alors stocké dans une mémoire de l'entité fournisseur, tandis que l'entité client se borne à renvoyer les paquets témoins qu'elle reçoit de l'entité fournisseur. Revendications 1. Procédé pour estimer la qualité d'un échange de données, via un réseau étendu, notamment le réseau 5 Internet, dans lequel: a) on émet, à partir d'une première entité équipée au moins d'un module mémoire, au moins un paquet de données requête, via un réseau étendu, à une seconde entité, b) dès réception du paquet requête par la seconde entité, on réémet un paquet réponse vers la première entité, et c) dès réception du paquet réponse, auprès de la première entité, on stocke dans le module mémoire de la première entité des paramètres relatifs à une qualité d'échange de paquets entre les première et seconde entités, comprenant au moins un temps de transit des paquets via le réseau étendu. 2. Procédé selon la revendication 1, dans lequel: bl) on prévoit un traitement des données du paquet requête, comportant au moins une interprétation desdites données, dès réception du paquet requête par la seconde entité, et cl) dans le module mémoire de la première entité, on stocke en outre, parmi lesdits paramètres, une durée de traitement par la seconde entité comprenant au moins un temps d'interprétation du paquet requête. 3. Procédé selon la revendication 2, dans lequel: b2) on prévoit en outre une mise en forme de données pour former un paquet réponse, après ladite interprétation des données du paquet requête par la seconde entité, et dans lequel ladite durée de traitement par la seconde entité comprend en outre un temps de mise en forme du paquet réponse. 4. Procédé selon l'une des revendications 1 à 3, dans lequel la première entité émet répétitivement une pluralité de paquets requêtes à différents instants prédéterminés, pour stocker successivement dans ledit module mémoire lesdits paramètres en fonction desdits différents instants. 5. Procédé selon la revendication 4, dans lequel ledit module mémoire stocke un historique de la qualité des échanges entre les première et seconde entités. 6. Procédé selon l'une des revendications 4 et 5, dans lequel ledit module mémoire stocke lesdits paramètres sous forme de moyennes respectives associées chacune à un paramètre. 7. Procédé selon l'une des revendications 4 à 6, dans lequel la première entité au moins est équipée en outre d'un système d'exploitation, agencé pour gérer en tâche de fond l'envoi et la réception des paquets, ainsi que la mémorisation des paramètres dans le module mémoire. 8. Procédé selon l'une des revendications 1 à 7, dans lequel ledit paquet requête est un paquet témoin comportant des données d'instructions de réémission dudit paquet témoin en tant que paquet réponse de la seconde entité à la première entité. 9. Procédé selon l'une des revendications 1 à 8, dans lequel lesdits paramètres relatifs à la qualité de l'échange comportent en outre un taux d'erreur dans le paquet échangé. 10. Procédé selon l'une des revendications 1 à 9, dans lequel, lesdits paquets transitant par au moins une entité intermédiaire de routage pendant l'émission et/ou la réémission des paquets, lesdits paramètres relatifs à la qualité de l'échange comportent en outre au moins un paramètre associé à ladite entité intermédiaire et relatif à une durée de transit et/ou à un taux d'erreur dans les paquets transités par cette entité intermédiaire. 11. Procédé selon la revendication 10, dans lequel, lesdits paquets transitant par une pluralité d'entités intermédiaires de routage pendant l'émission et/ou la réémission des paquets, lesdits paramètres relatifs à la qualité de l'échange comportent une pluralité de paramètres associés chacun à une entité intermédiaire et relatifs à une durée de transit et/ou à un taux d'erreur dans les paquets transités par cette entité intermédiaire. 12. Procédé selon l'une des revendications précédentes, dans lequel la première entité est une entité client et la seconde entité est une entité fournisseur de services WEB, et dans lequel ladite seconde entité est agencée pour accéder au contenu du module mémoire. 13. Produit programme d'ordinateur, stocké dans une mémoire d'une installation informatique équipée d'un module de communication via un réseau étendu, ou sur un support destiné à coopérer avec un lecteur de ladite installation, ou encore encodé pour être téléchargé vers ladite installation informatique à partir d'un serveur distant via le réseau étendu, caractérisé en ce qu'il comporte des instructions pour mettre en oeuvre au moins: - les étapes a) et c) du procédé selon l'une des revendications précédentes, lorsque lesdites instructions sont chargées dans une mémoire de travail de ladite installation informatique en tant que première entité, - et l'étape b) du procédé selon l'une des revendications précédentes, lorsque lesdites instructions sont chargées dans une mémoire de travail de ladite installation informatique en tant que seconde entité.