Brevet FR2888069A1 — publié le 20070105

La présente invention concerne un procédé d'échange de données structurées entre au moins un serveur et un client, un serveur, un système comprenant ce serveur, un client de ce système, un programme pour un ordinateur formant un serveur et un programme pour un ordinateur formant le client de ce système. Elle s'applique en particulier à l'exploitation automatique par le client d'informations proposées par le serveur. Les informations se présentent sous forme de données dont la structure est généralement spécifique au serveur fournissant ces données. Ainsi un utilisateur client souhaitant accéder à ces données doit connaître la structure de données du serveur. II est connu d'échanger des données entre un client et un serveur reliés entre eux par le réseau Internet. Ainsi, dans le cas particulier d'un serveur proposant les services d'un moteur de recherche, le client accède à une page Internet d'accueil et formule une requête en saisissant par exemple des mots clefs dans un champ de saisie de cette page d'accueil. La page d'accueil est généralement créée en langage de balisage de texte HTML (acronyme anglais de HyperText Markup Language). En réponse à la requête, le moteur de recherche propose généralement une page en HTML contenant des citations comportant chacune les références d'un site Internet (dont les pages contiennent les mots clefs saisis) et un lien permettant d'accéder à ce site. L'exploitation automatique des informations contenues dans la réponse fournie par le moteur de recherche peut être réalisée par le client en exécutant un programme d'analyse de cette page de réponse. Le programme d'analyse identifie des repères particuliers dans la page. Toutefois, si la présentation de la page de réponse évolue, les repères et le programme d'analyse deviennent caduques et doivent être remis à jour. Pour faciliter l'obtention automatique d'informations par un client, il a été proposé dans l'état de la technique de normaliser la présentation des informations fournies par un serveur, par exemple conformément aux spécifications du type TV-Anytime ou du type à syndication vraiment simple RSS (conformément à l'acronyme anglais Really Simple Syndication). Ces spécifications permettent d'organiser un échange de données structurées entre un serveur et un client en langage de balisage extensible XML (conformément à l'acronyme anglais eXtensible Markup Language). Toutefois, la définition des spécifications de type TV-Anytime ou RSS requiert un travail de consultation des fournisseurs de services intéressés et de standardisation relativement important pour décrire la syntaxe et la sémantique des requêtes et réponses. De plus, bien que l'accès d'un utilisateur client aux données soit simplifié, celui-ci doit se familiariser avec les spécifications précitées de la structure de données avant de pouvoir l'utiliser. Enfin, les spécifications de type TV-Anytime ou RSS sont chacune propre à un domaine particulier, à savoir le domaine audiovisuel pour la spécification de TV-Anytime et le domaine journalistique pour la spécification RSS. Par conséquent, ces spécifications ne sont pas prévues pour être transposées à d'autres domaines. L'invention a notamment pour but de faciliter l'échange de données structurées, notamment de type XML, entre un client et un serveur sans recourir à des travaux importants de normalisation. A cet effet, l'invention a pour objet un procédé d'échange de données entre au moins un premier serveur et un client, le procédé étant du type comprenant une étape de formulation d'une requête à l'attention d'un second serveur qui, le cas échéant, peut être le premier serveur, fournissant des données structurées, notamment de type XML, caractérisé en ce qu'il comprend une étape préalable de fourniture par le premier serveur au client d'informations relatives aux structures de requête et de réponse conformes à la structure de données en vigueur sur le second serveur. Cette étape préalable permet de rendre facilement accessible au client des données proposées par un serveur, ceci sans qu'il soit nécessaire de recourir à des systèmes de normes spécifiques à des domaines particuliers et difficiles à établir. Le cas échéant, l'accès au serveur peut se faire automatiquement au moyen d'un programme d'accès établi à partir des structures de requête et de réponse communiquées par le serveur. Sur Internet, ces structures sont généralement indépendantes de la présentation de la page HTML qui, habituellement, permet l'accès aux services proposés par un serveur. Une modification de la présentation de cette page est donc sans conséquence sur le fonctionnement du programme d'accès aux données. L'utilisateur client peut donc, à partir d'un site Internet hébergé par un premier serveur, générer une requête vers un second serveur, dont le contenu est mentionné par ce site, par exemple sous forme de publicité, et sa base de données, en fonction des informations que cette base est susceptible de lui fournir. Grâce à l'invention, le client est informé des structures de requête et de réponse applicables aux données de la base du serveur fournisseur de données, même si ces structures sont spécifiques et non normées. Ceci permet au client de recueillir, éventuellement de façon automatique, des données de la base du serveur en s'affranchissant du format de la page Internet de présentation d'un service proposé par le serveur. Les informations relatives à la structure de requête comprennent au moins une définition choisie parmi une définition d'un protocole de transfert de la requête, une définition d'une adresse de serveur, une définition d'une commande, et une définition d'au moins un paramètre identifié par un nom, un type et une unité, s'il est de type numérique. De manière optionnelle, ces informations peuvent également comprendre: un groupe d'au moins deux paramètres, mis en relation à l'aide d'opérateurs logiques; - pour chaque paramètre, un commentaire descriptif, une liste de valeurs attendus, une valeur minimale, une valeur maximale et une valeur par défaut; une liste d'éléments à inclure dans la réponse. Par ailleurs, les informations relatives à la structure de réponse et fournies au client comprennent au moins une définition choisie parmi une définition d'un nom de structure de données attendue en réponse et une définition d'au moins un élément de la réponse. identifié par un nom, un type et une unité, s'il est de type numérique. Avantageusement, elles peuvent également comprendre, pour chaque élément, un nom, un type, une liste de valeurs possibles, un commentaire descriptif et, si l'élément est de type numérique, une unité et une cardinalité. Cela permet en effet de pouvoir replacer à la réception de la réponse, le contenu de chaque élément à l'endroit approprié, par exemple, dans une base de données client, avec ou sans conversion du codage du serveur au codage chez le client. Selon un mode de réalisation particulier de l'invention, le premier et le second serveurs forment un seul et même serveur. De manière optionnelle, l'étape de fourniture d'informations est complétée par une étape de présentation desdites informations à l'aide d'un programme d'interface exécuté par le client. Le programme d'interface génère, selon un mode de réalisation particulier, au moins une fenêtre présentant ces informations, par exemple sous forme de page HTML. Le contenu de cette fenêtre est généralement rédigée dans un langage ordinaire, accessible par un utilisateur qui n'est pas familier des langages informatiques. Le programme d'interface peut en outre présenter, d'une part, des éléments descriptifs décrivant les informations relatives aux structures de requête et de réponse et, d'autre part, des éléments d'assistance à la formulation d'une requête. Le cas échéant, au moins un des éléments descriptifs comprend une liste d'informations susceptibles de faire partie d'une réponse, les éléments d'assistance à la formulation d'une requête permettant de réaliser un choix parmi les informations de cette liste. Cette liste peut être notamment une liste de valeurs affectées à un paramètre. Par exemple, différentes valeurs NOM1 , NOM2 , etc. peuvent être affectées à un paramètre nom de société . L'invention évite ainsi à l'utilisateur d'avoir à formuler sa requête directement en langage XML, cette requête étant créée par choix de valeurs dans la liste proposée à l'aide d'un élément d'assistance associé au paramètre correspondant. L'étape de formulation de requête peut en outre comprendre l'incorporation dans la requête de données propres au client. Le procédé peut comprendre une étape d'émission de la requête vers le second serveur à la suite d'une action volontaire d'un utilisateur sur le client. Le procédé peut également comprendre une étape d'émission automatique de la requête par le client vers le second serveur, par exemple conformément à une séquence programmée par un utilisateur dans le client. Ainsi, une requête susceptible d'être utilisée périodiquement, par exemple une requête de cours de valeurs boursières, peut être mémorisée par le client (ce qui évite de la reformuler chaque fois) et transmise automatiquement au serveur correspondant. De manière optionnelle, l'étape de présentation d'informations est initialisée par l'activation volontaire d'un lien dans une page Internet présentée par le premier serveur. Ainsi, l'utilisateur client reçoit les informations relatives à la structure de données du serveur uniquement s'il envisage de formuler une requête à l'attention de ce serveur, ce qui évite d'utiliser les ressources du client inutilement. Le procédé comprend également une étape de transmission de réponse par le second serveur, la réponse étant conforme à la structure de réponse transmise préalablement au client. L'invention a également pour objet un serveur caractérisé en ce qu'il comprend des moyens de fourniture à un client d'informations relatives aux structures de requête et de réponse conformes à la structure de données en vigueur sur un serveur fournissant des données structurées, notamment de type XML. Optionnellement, les deux serveurs décrits ci-dessus forment un seul et même serveur. L'invention a également pour objet un système comprenant un serveur et un client reliés entre eux au moyen d'un réseau, le client comportant des moyens de formulation de requête à l'attention d'un second serveur qui, le cas échéant, peut être le premier serveur, fournissant des données, notamment de type XML, caractérisé en ce que le premier serveur est tel que défini ci-dessus. L'invention a également pour objet un client d'un système tel que défini ci-dessus, caractérisé en ce qu'il comprend des moyens de présentation des informations fournies par le premier serveur. Optionnellement, le client comprend des moyens d'incorporation de données qui lui sont propres dans la requête à l'attention du second serveur. Le client peut également comprendre des moyens d'émission de la requête vers le second serveur, automatiquement ou à la suite d'une action volontaire d'un utilisateur. De façon optionnelle, le client selon l'invention comprend également des moyens d'activation d'un lien dans une page Internet proposée par le premier serveur, déclenchant la fourniture d'informations par ce serveur. L'invention a également pour objet un programme pour un ordinateur formant un serveur tel que décrit ci-dessus, caractérisé en ce qu'il fournit automatiquement au client des informations relatives aux structures de requête et de réponse conformes à la structure de données d'un second serveur. L'invention a également pour objet un programme pour un ordinateur formant un client d'un système tel que défini ci-dessus, caractérisé en ce qu'il génère une interface de présentation d'informations fournies au client par le serveur. De manière optionnelle, l'interface générée par ce programme d'ordinateur: - comprend une fenêtre, permettant d'afficher par exemple une page HTML, donnant accès ou présentant les informations fournies au client par le serveur; - présente, d'une part, des éléments descriptifs décrivant les informations relatives aux structures de requête et de réponse et, d'autre part, des éléments d'assistance à la formulation d'une requête. L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins dans lesquels: la figure 1 est un schéma d'un système d'échange de données selon un mode de réalisation particulier de l'invention; la figure 2 représente les étapes successives d'un procédé d'échange de données selon l'invention, mis en oeuvre dans le système de la figure 1; la figure 3 est un schéma d'une structure de requête et de réponse susceptible d'être présentée en langage XML. 35 On a représenté sur la figure 1 un système 10 selon l'invention pour l'échange de données entre un client 12 et un serveur 14 par l'intermédiaire d'un réseau classique 16 reliant le client 12 et le serveur 14, par exemple le réseau Internet. Le client 12 comprend un ordinateur comportant une unité centrale 20 munie d'un processeur 20P, d'une mémoire 20M, par exemple de type RAM (acronyme anglais de Random Access Memory), et d"entrées-sorties 20A, 20B. L'ordinateur comporte également des éléments 22 d'interface pour un utilisateur, par exemple un clavier, un écran et une souris, et une base de données 24. Le serveur 14 comprend un ordinateur comportant une unité centrale 26 et une base 10 de données 28. L'unité centrale 26 est munie, en général, d'un processeur 26P, d'une mémoire 26M et d'entrées-sorties 26A, 26B. La base 24 du client 12 peut, le cas échéant, être renseignée par des données de la base 28 du serveur 14, comme précisé par la suite. En variante, le client 12 et/ou le serveur 14 peuvent comprendre plusieurs bases de 15 données. De même, le système 10 peut comprendre un serveur central donnant accès à différents serveurs fournissant des données. On décrira ci-dessous, en référence à la figure 2, un procédé d'échange de données mis en oeuvre par le système 10. Dans ce qui suit, on appellera utilisateur client, un utilisateur du client 12. Initialement (étape préliminaire 30), l'utilisateur client accède, par l'intermédiaire du réseau 16, à une page Internet proposée par le serveur 14. Cette page Internet présente des éléments formant des liens informatiques donnant accès à des données susceptibles d'être fournies par le serveur 14. L'utilisateur client, intéressé par des données proposées par le serveur 14, active 25 volontairement un lien (étape 32) donnant accès à ces données à l'aide d'un élément 22 d'interface utilisateur. Cette étape 32 déclenche une étape 36 de fourniture, par le serveur 14, d'informations au client 12. Au cours de l'étape 36, des moyens classiques (comprenant notamment l'unité centrale 26 du serveur 14) fournissent au client 12 des informations 38 comprenant des définitions relatives à des structures de requête 40 et de réponse 42 conformes à la structure de données en vigueur sur le serveur 14. Ces moyens classiques comprennent notamment l'unité centrale 26 du serveur 14, sur lequel s'exécute un programme informatique. Les informations 38 peuvent être transmises au client 12 dans un fichier de définition en langage XML programmé par un exploitant d'un service proposé par le serveur 14. Les informations 38 relatives aux structures de requête 40 et de réponse 42 définissant ces structures peuvent être organisées de façon arborescente comme cela est schématisé sur la figure 3. Ainsi., la définition de la structure de requête 40 comprend au moins une définition du mode de la requête, c'est à dire du protocole de transfert de la requête. Cette dernière peut être par exemple de type 44a, conforme au protocole de transfert hypertexte HTTP (acronyme anglais de HyperText Transfer Protocol), ou de type 44b, conforme au protocole SOAP (acronyme anglais de Simple Object Access Protocol). Pour chaque protocole défini, la définition de la structure de requête 40 comprend également une adresse de serveur et une commande. La définition de la structure de requête 40 peut également comprendre une définition 46 d'au moins un paramètre d'interrogation de la base de données 28 du serveur 14, celui-ci étant identifié par un nom, un type (booléen, entier, chaîne de caractères, etc.) et une unité, s'il est de type numérique. La définition de la structure de requête 40 peut également comporter une définition d'un groupe d'au moins deux paramètres, mis en relation à l'aide d'opérateurs logiques, tels que OU ou ET. Chacun des paramètres de la structure de requête 40 peut être précisé par un commentaire descriptif, une liste de valeurs attendues, une valeur minimale, une valeur maximale et une valeur par défaut. La définition de la structure de requête 40 peut également comprendre une liste d'éléments à inclure dans la réponse, ces éléments étant à choisir parmi tous les éléments que peut fournir le serveur 14 dans la réponse. La définition de la structure de réponse 42 peut comprend une définition 48 d'un nom d'une structure de données attendue en réponse, et une définition d'au moins un élément de cette structure, associé éventuellement à un ou plusieurs attributs pouvant prendre des valeurs particulières. Ainsi, dans le cas d'une base de données répertoriant des valeurs boursières de sociétés, nom de société et pays du marché boursier peuvent être des éléments. Ces éléments peuvent prendre différentes valeurs NOM1 , NOM2 , etc. et PAYS1 , PAYS2 , etc. Pour chaque élément, la définition de la structure de réponse 42 peut comprendre une définition d'un nom d'élément, d'un type (booléen, entier, chaîne de caractères, etc.), d'une liste de valeurs possibles, la signification de ces valeurs et d'une unité et d'une cardinalité, c'est-à- dire le nombre d'occurrences d'une identité, uniquement si les valeurs associées à l'élément sont numériques. Les définitions ci-dessus peuvent être appréhendées par le client 12 directement à partir d'un programme capable de comprendre une structure de données en syntaxe XML selon le schéma présenté ci-dessous: type="QueryResponseDescription Type"/> 25 La structure générale des du fichier de définition contenant la description des structures de requêtes (40) et de réponse (42) est donc la suivante: Le procédé selon l'invention peut être réalisée par exemple selon les deux modes suivants. Dans le premier mode de réalisation, le serveur est interrogé à l'aide du protocole de transfert HTTP. Dans l'exemple de l'interrogation d'un serveur contenant des données boursières, selon ce premier mode de réalisation, la structure de requête 40 présentée dans le fichier de définition, sous la forme d'un programme en langage XML, peut être du type ci-dessous: adresse Internet serveur table XML Choisir le code de la valeur parmi la liste des valeurs indiquées ici. Exemple: "CODEZ" pour "SOCIETEI " SOCIETE2 SOCIETE1 Langage des éléments en réponse quand plusieurs langues sont disponibles Français English Dans le second mode de réalisation, le serveur est interrogé à l'aide du protocole de 45 transfert SOAP. L'utilisateur client peut donc interroger le serveur à l'aide de ce protocole selon les spécifications suivantes, définissant les entrées et sorties, les codages et les liens à utiliser par les services de données: Interface de Service WSDL pour toute API de fournisseur de données. Ce document WSDL définit les appels de l'API pour le port d'accès any data provider get Data binding La structure de requête présentée dans le fichier de définition se présente alors sous la forme suivante: définition des paramètres de même type que pour le premier mode de réalisation 15 La structure de réponse 42 présentée dans le fichier de définition, sous la forme d'un programme en langage XML., ne dépend pas du protocole utilisé et peut être du type ci-dessous: Enveloppe de la réponse Nom courant de la valeur Code de la valeur selon la codification "xxxx". Exemple: "CODEZ" pour "SOCIETEI " Cours de la valeur en Euros Conseil des analystes Vendre Souspondérer Conserver Surpondérer 45 50 Acheter Date et heure du cours de la valeur La structure de réponse 42 peut également être du type présenté ci-dessous. Elle diffère du type présenté précédemment en ce qu'elle permet de renvoyer une arborescence d'éléments, et, ainsi, dans le cadre de l'exemple, il est possible de renvoyer des informations boursières sur plusieurs sociétés dans la même réponse: Enveloppe de la réponse Code de la valeur selon la codification "xxxx". Exemple: "CODE1 " pour "SOCIETEI " Cours de clôture de la valeur en Euros variation du cours par rapport au cours de clôture précédent en pourcent URL pour accéder à la page complète des Echos sur la valeur courante Date et heure du cours de la ou des valeurs qui suivent A l'aide du fichier fourni par le serveur 14, par exemple du type d'au moins un des programme ci-dessus, le client 12 peut formuler une requête adaptée aux informations qu'il veut obtenir de la part du serveur 14. La requête dont les éléments ont été explicités par un fichier de définition selon l'exemple peut être formulée à l'aide du protocole de transfert http, de la façon suivante: http://adresse lnternet senneur/tableXML?symbole=CODEZ+CODE2&language=fr. L'utilisateur peut également formuler une requête en choisissant les éléments qu'il veut voir apparaître dans la réponse: http://adresse lnternetserveur/tableXML?symbole=CODE1&fields= /response/Code Valeur/Cours/text()+/response/Code Valeur/Varia tion/text( Selon le second mode de réalisation, la requête relative à l'exemple peut être formulée de la façon suivante: Toutefois, pour que les informations 38 définissant les structures de requête 40 et de réponse 42 soient accessibles par un utilisateur qui n'est pas familier des langages informatiques, de préférence, le procédé comprend une étape 50 de présentation au cours de laquelle le client génère, à l'aide de moyens de présentation 20, une fenêtre contenant par exemple une page HTML, formant une interface donnant accès ou présentant des informations fournies au client 12 par le serveur 14, plus particulièrement présentant les définitions des structures 40, 42. Ces moyens de présentation 20 comprennent un programme d'interface non spécifique au serveur 14, téléchargé et installé au préalable sur le client. L'envoi au client 12 du programme d'interface peut être déclenché à la suite d'une commande de téléchargement volontaire du client 12. L'envoi au client 12 du fichier de définition avec son type MIME peut être déclenché par l'activation du lien prévue à l'étape 32. L'exécution du programme d'interface par le client 12 est déclenchée automatiquement par la réception du fichier de définition envoyé par le serveur 14 qui comporte un type MIME ( par exemple: application/x-QRDprogram ) associé à ce programme. Par exemple, si le programme informatique est destiné à exécuter les fichiers de format .QRD , l'extension du fichier de définition est .QRD et le type MIME correspondant envoyé est alors application/x-QRD-program .Ce programme extrait les informations 38 contenues dans le fichier de définition pour créer, dans la page HTML de présentation affichée à l'écran du client 12, des éléments clairs décrivant les informations relatives aux structures de requête 40 et de réponse 42. Les éléments descriptifs des structures 40, 42 apparaissant sur la page Internet sont par exemple des listes de valeurs ou un texte présentant les différents paramètres dans ce mode de réalisation. De préférence, le programme d'interface crée également, dans la page HTML de présentation affichée à l'écran du client 12, des éléments d'assistance à la formulation de requêtes. Ainsi, au moins un des éléments descriptifs de la page HTML de présentation peut comprendre une liste d'informations susceptibles de faire partie d'une réponse, les éléments d'assistance à la formulation d'une requête permettant de réaliser un choix parmi les informations de cette liste, par exemple à l'aide de boutons ou d'un champ de saisie. Le programme d'interface est également utilisé pour décider de la destination des éléments contenus dans la réponse avec conversion éventuelle au codage utilisé chez le client. L'étape 50 de présentation d'informations est suivie d'une étape 52 au cours de laquelle l'utilisateur client formule une requête à l'attention du serveur 14. Cette étape 52 peut comprendre une sous-étape 54 de formulation de la requête à l'aide des éléments d'assistance à la formulation de requête proposés par le programme d'interface et de moyens classiques tels qu'un élément d'interface 22 du client 12 (clavier, souris, etc.). L'étape 52 peut également comprendre une sous-étape 56 d'incorporation dans la requête de données propres au client 12, plus particulièrement de données contenues dans la base 24 du client 12. La sous-étape 56 peut être exécutée notamment à l'aide de moyens comportant un logiciel utilitaire non spécifique au serveur 14 stocké sur l'unité centrale 20 du client 12. Après avoir formulé la requête, le client 12 émet cette requête vers le serveur 14, au cours d'une étape 58. Cette transmission peut se faire à la suite d'une action volontaire de l'utilisateur sur le client 12 (sousétape 60 de l'étape 58) ou automatiquement (sous-étape 62 de l'étape 58). Ainsi, au cours de la sous-étape 60, l'utilisateur client peut déclencher manuellement la transmission de la requête par exemple en cliquant sur un bouton de la fenêtre de présentation. Au cours de la sous-étape 60, la transmission de la requête est pilotée par des moyens classiques du client comprenant un élément 22 d'interface utilisateur (clavier, souris, etc.) et l'unité centrale 20 du client 12. La requête est transmise au serveur 14 par l'intermédiaire du réseau 16. Au cours de la sous-étape 62, la requête est émise automatiquement par le client 12 vers le serveur 14, par exemple conformément à une séquence programmée par l'utilisateur dans le client 12. Par exemple, au cours de la sous-étape 62, un formulaire est présenté à l'utilisateur client. Celui-ci indique, en remplissant des champs de saisies ou en cliquant sur des boutons numériques, à quelles échéances la requête doit être transmise automatiquement au serveur 14. Ce formulaire peut être généré par des moyens comprenant un logiciel utilitaire, par exemple le programme d'interface décrit ci-dessus, stocké dans l'unité centrale 20 du client 12. Au cours de la sous-étape 62, la transmission de la requête est pilotée par des moyens classiques comprenant l'unité centrale 20 du client 12. La requête est transmise au serveur 14 par l'intermédiaire du réseau 16. Après réception de la requête par le serveur 14, celui-ci la traite et transmet une réponse au client 12 au cours d'une étape 64. La réponse est conforme à la structure de réponse 42, incluse dans le fichier de définition présenté au préalable à l'utilisateur client. Dans le cas de la structure de réponse 42 donnée en exemple, la réponse selon le premier mode de réalisation peut être la suivante: SOCI ETE 1 CODE1 23.25 3 Selon le second mode de réalisation, la réponse à la requête donnée en exemple est: SOCIETE1 CODE1 23.25 http:// adresse serveur/accesSOAP/symbole=CODE1 La réponse peut également être constituée par une arborescence d'éléments permettant de fournir plusieurs données distinctes, si bien qu'un seul envoi par le serveur 14 peut contenir toutes les données requises par le client 12. Le cas échéant, certaines données figurant dans la réponse du serveur 14 et provenant de la base 28 de ce serveur 14 sont affectées, avec conversion éventuelle au codage utilisé chez le client, au cours d'une étape 66, à la base de données 24 du client 12. Cette affectation peut être réalisée par un logiciel utilitaire stocké sur l'unité centrale 20 du client 12. Le système et le procédé décrits ci-dessus permettent donc à un utilisateur client de générer une requête vers un serveur 14 et d'exploiter au mieux sa réponse quelle que soit la structure de données en vigueur sur ce serveur 14. Le système d'échange de données selon l'invention ne se limite pas au mode de réalisation décrit ci-dessus. En particulier, comme illustré en pointillés sur la figure 1, le système peut comprendre deux serveurs, à savoir le serveur 14 en trait plein (premier serveur) et le serveur 14' en pointillés (second serveur) plutôt qu'un seul et même serveur comme décrit précédemment. Dans cette configuration, le premier serveur 14 fournit au client des informations relatives aux structures de requête et de réponse conformes à la structure de données en vigueur sur le second serveur 14'. REVENDICATIONS 1. Procédé d'échange de données entre au moins un premier serveur (14) et un client (12), le procédé étant du type comprenant une étape (52) de formulation d'une requête à l'attention d'un second serveur (14, 14') qui, le cas échéant, peut être le premier serveur, fournissant des données structurées, notamment de type XML, caractérisé en ce qu'il comprend une étape préalable (36) de fourniture par le premier serveur (14) au client (12) d'informations relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données en vigueur sur le second serveur (14, 14'). 2. Procédé d'échange de données structurées selon la revendication 1, caractérisé en ce que les informations (38) relatives à la structure de requête (40), fournies au client (12), comprennent au moins une définition choisie parmi une définition (44a, 44b) d'un protocole de transfert de la requête, une définition d'une adresse de serveur, une définition d'une commande, et une définition (46) d'au moins un paramètre identifié par un nom et un type. 3. Procédé d'échange de données structurées selon la revendication 2, caractérisé en ce que les informations (38) relatives à la structure de requête (40), fournies au client (12), peuvent comprendre: - un groupe d'au moins deux paramètres, mis en relation à l'aide d'opérateurs logiques; pour chaque paramètre, un commentaire descriptif, une liste de valeurs attendues, une valeur par défaut et, si ce paramètre est de type numérique, une unité, une valeur minimale et une valeur maximale; - une liste d'éléments et d'attributs à inclure dans la réponse. 4. Procédé d'échange de données structurées selon les revendications 1 à 3, caractérisé en ce que les informations (38) relatives à la structure de réponse (42), fournies au client (12), comprennent au moins une définition choisie parmi une définition d'un nom (48) de structure de données attendue en réponse et une définition d'au moins un élément de la réponse. 5. Procédé d'échange de données structurées selon la revendication 4, caractérisé en ce que les informations (38) relatives à la structure de réponse (42), fournies au client (12), peuvent comprendre, pour chaque élément, un nom, un type, une liste de valeurs possibles, un commentaire descriptif et, si l'élément est de type numérique, une unité et une cardinalité, associé éventuellement à un ou plusieurs attributs, avec, pour chaque attribut, un nom, un type, une liste de valeurs possibles, un commentaire descriptif et, si l'attribut est de type numérique, une unité et une cardinalité. 6. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 5, caractérisé en ce que l'étape (36) de fourniture d'informations est complétée par une étape de présentation (50) de ces informations à l'aide d'un programme d'interface exécuté par le client (12). 7. Procédé d'échange de données structurées selon la revendication 6, caractérisé en ce que le programme d'interface génère une fenêtre, contenant par exemple une page HTML, présentant ces informations. 8. Procédé d'échange de données structurées selon la revendication 6 ou 7, caractérisé en ce que le programme d'interface présente, d'une part, des éléments descriptifs décrivant les informations (38) relatives aux structures de requête (40) et de réponse (42) et, d'autre part, des éléments d'assistance à la formulation d'une requête. 9. Procédé d'échange de données structurées selon la revendication 8, caractérisé en ce qu'au moins un des éléments descriptifs comprend une liste d'informations susceptibles de faire partie d'une réponse, les éléments d'assistance à la formulation d'une requête permettant de réaliser un choix parmi les informations de cette liste. 10. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'étape (52) de formulation de requête comprend l'incorporation (56) dans la requête de données propres au client. 11. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend une étape (60) d'émission de la requête vers le second serveur (14, 14') à la suite d'une action volontaire d'un utilisateur sur le client (12). 12. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend une étape (62) d'émission automatique de la requête par le client (12) vers le second serveur (14, 14'), par exemple conformément à une séquence programmée par un utilisateur dans le client (12). 13. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 12, caractérisé en ce que l'étape (36) de fourniture d'informations est déclenchée par une étape (32) d'activation volontaire d'un lien dans une page Internet proposée par le premier serveur (14). 14. Procédé d'échange de données structurées selon l'une quelconque des revendications 1 à 13, caractérisé en ce qu'il comprend une étape (64) de transmission au client (12) par le second serveur (14, 14') d'une réponse à la requête émise par ledit client (12), la réponse étant conforme à la structure de réponse (42). 15. Serveur caractérisé en ce qu'il comprend des moyens (26) de fourniture à un client (12) d'informations (38) relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données en vigueur sur un serveur (14, 14') fournisseur de données structurées. 16. Serveur selon la revendication 15, caractérisé en ce qu'il forme le serveur (14) fournisseur de données structurées. 17. Système comprenant au moins un premier serveur (14) et un client (12) reliés entre eux au moyen d'un réseau (16), le client (12) comportant des moyens (22) de formulation de requête à l'attention d'un second serveur (14, 14'), qui, le cas échéant, peut être le premier serveur, caractérisé en ce que le premier serveur (14) est selon la revendication 15. 18. Client d'un système selon la revendication 17, caractérisé en ce qu'il comprend des moyens de présentation (20) des informations (38) fournies par le premier serveur (14). 19. Client selon la revendication 18, caractérisé en ce qu'il comprend des moyens d'incorporation (20) de données qui lui sont propres dans la requête à l'attention du second serveur (14, 14'). 20. Client selon la revendication 18 ou 19, caractérisé en ce qu'il comprend des moyens d'émission (20, 22) de la requête vers le second serveur (14,14'), automatiquement ou à la suite d'une action volontaire d'un utilisateur. 21. Client selon l'une quelconque des revendications 18 à 20, caractérisé en ce qu'il comprend des moyens d'activation (20, 22) d'un lien dans une page Internet proposée par le premier serveur (14), déclenchant la fournitures des informations (38) par ledit serveur (14) au client (12). 22. Programme pour un ordinateur formant serveur (14) selon la revendication 15, caractérisé en ce qu'il fournit automatiquement au client (12), suite à l'activation d'un lien par ledit client (12), des informations (38) relatives aux structures de requête (40) et de réponse (42) conformes à la structure de données d'un second serveur (14, 14'). 23. Programme pour un ordinateur formant un client (12) d'un système selon la revendication 17, caractérisé en ce qu'il génère une interface de présentation d'informations fournies au client (12) par le premier serveur (14). 24. Programme d'ordinateur selon la revendication 23, caractérisé en ce que l'interface générée comprend au moins une fenêtre, contenant par exemple une page HTML, donnant accès ou présentant les informations fournies au client (12) par le premier serveur (14). 25. Programme d'ordinateur selon la revendication 23 ou 24, caractérisé en ce que l'interface générée présente, d'une part, des éléments descriptifs décrivant les informations relatives aux structures de requête (40) et de réponse (42) et, d'autre part, des éléments d'assistance à la formulation d'une requête.