Brevet FR2944119A1 — publié le 20101008

PROCEDE D'INTERROGATION DE BASES DE DONNEES STRUCTUREES La présente invention concerne un procédé d'interrogation d'une pluralité de bases de données structurées interrogeables, dans un réseau informatique, au travers d'interfaces d'interrogation hétérogènes. Elle concerne plus particulièrement un tel procédé pour l'interrogation de bases hétérogènes de données structurées de propriété industrielle, par exemple de données structurées se rapportant à des brevets d'invention. Le développement des réseaux informatiques et, notamment, l'Internet, a rendu possible la mise à disposition de données de tous types. Pour identifier aisément la plupart de ces données, l'utilisation des moteurs de recherche, voire des méta-moteurs de recherche, est indispensable. Une technique courante utilisée par les moteurs de recherche consiste à parcourir les liens hypertextes identifiés dans les sites de l'Internet, qui référencent eux-mêmes d'autres sites comprenant de même des liens hypertextes dans leurs pages, en vue constituer une grande base de données indexée interrogeable en utilisant une combinaison logique de mots-clés. Etant donné que chaque moteur de recherche utilise son propre algorithme pour collecter les données et pour les indexer, les résultats d'une même recherche sont différents d'un moteur de recherche à un autre, et des données sont susceptibles d'être trouvées à partir d'un moteur de recherche mais pas à partir d'un autre. Pour pallier à cet inconvénient, les méta-moteurs de recherche proposent aux utilisateurs une unique interface de recherche, qui est généralement réduite à une zone de texte, pour saisir une combinaison logique de mots-clés. Cette interface offre aussi parfois la possibilité de sélectionner, parmi une liste de moteurs de recherche, ceux à utiliser pour effectuer la recherche. Les résultats fournis par chaque moteur de recherche sont alors consolidés, c'est-à-dire regroupés, pour être ensuite présentés à l'utilisateur. Malgré tout, un certain nombre de données ne sont accessibles, ni aux moteurs, ni aux méta-moteurs de recherche. Ce sont les données structurées des bases de données. En effet, ces données structurées sont accessibles au travers de formulaires d'interface complexes. Les sites ou services d'un réseau informatique, par exemple l'Internet, qui offrent une interface d'accès à leur base de données structurées, sont appelés des fournisseurs ou fournisseurs de données. Il existe principalement deux types d'interfaces . les interfaces proposant des champs liés ou pas entre eux par des opérateurs booléens, et les interfaces proposant une zone de texte libre utilisant une liste d'identifiants de champs utilisables avec une syntaxe propre à chaque fournisseur. L'utilisation de multiples interfaces pose de nombreux problèmes. Au niveau technique, chaque interface impose des contraintes spécifiques, comme, par exemple, la limitation des opérateurs, des termes utilisables par champ ou des formats de date différents, et elles n'offrent pas fréquemment la possibilité de rechercher dans le texte intégral des documents contenus dans les bases. Au niveau sémantique, un même document peut être référencé de manières différentes auprès de chaque fournisseur et l'utilisateur doit connaître la correspondance entre les types de références. Dans un exemple, les données structurées disponibles auprès de fournisseurs sont les données liées à la propriété industrielle. Dans ce cas, les fournisseurs sont en général des offices nationaux, régionaux ou internationaux de propriété industrielle. Dans le cas où les données structurées sont des données de brevets d'invention, une personne, qui souhaite effectuer une recherche de qualité relativement à une technologie donnée, peut avoir à utiliser plusieurs dizaines d'interfaces, chaque fournisseur proposant sa propre interface. Il doit alors jongler longuement et difficilement de l'une à l'autre en tenant compte des différentes syntaxes, codes et formats propres à chaque interface en vue de tenter d'obtenir les données qu'il recherche. Un autre point que l'utilisateur ne peut pas gérer, s'il doit consulter séparément les fournisseurs, est le regroupement d'informations par famille. Une famille est, au sens large, une liste d'informations ou de documents ayant la même source. Dans la plupart des cas, l'utilisateur a besoin de connaître l'existence des membres de la famille ne serait-ce que pour avoir une version dans sa langue de l'information ou du document, si cette version existe. De plus, un regroupement par famille réduit la quantité de données à lire ou à traiter. Compte tenu de ce qui précède, un problème que se propose de résoudre l'invention est de réaliser un procédé d'interrogation d'une pluralité de bases de données structurées interrogeables, dans un réseau informatique, au travers d'interfaces d'interrogation hétérogènes, qui simplifie nettement le travail de l'utilisateur. La solution au problème ci-dessus proposée par l'invention a pour objet un procédé d'interrogation d'une pluralité de bases de données structurées interrogeables, au sein d'un réseau informatique, au travers d'interfaces d'interrogation hétérogènes, caractérisé en ce qu'il comporte les phases suivantes selon lesquelles : un utilisateur élabore une requête d'interrogation au travers d'une interface d'interrogation générique ; la requête d'interrogation est transformée en une pluralité de requêtes d'interrogation spécifiques des bases de données hétérogènes interrogées ; et la pluralité de requêtes d'interrogation spécifiques 15 est exécutée en vue d'obtenir des résultats en réponse à la requête d'interrogation de l'utilisateur, et en ce que la phase de transformation de la requête d'interrogation comprend une étape selon laquelle un arbre de l'expression de la requête est construit puis 20 développé de manière à obtenir un arbre développé, qui est traduit, pour former des arbres spécifiques de chacune des bases de données hétérogènes interrogées. De manière avantageuse, - pour l'élaboration de la requête d'interrogation, l'utilisateur utilise un 25 formulaire comportant un ou plusieurs champs liés entre eux par des opérateurs booléens et les données saisies dans ledit formulaire sont vérifiées dynamiquement avec un serveur, lors de l'élaboration de la requête ; - pour l'élaboration de la requête d'interrogation, 30 l'utilisateur utilise une zone de texte générique ; - la validation de la requête élaborée par l'utilisateur est assurée par un composant de traitement, qui comprend un analyseur syntaxique et un analyseur grammatical ; - pour former une requête spécifique d'une base de données, on crée des formulaires de manière itérative de sorte que, à chaque limitation rencontrée pour l'interrogation de ladite base de données, un nouveau formulaire est créé puis rattaché à l'arbre développé traduit ; - les formulaires créés sont optimisés en augmentant le nombre de termes de recherche par champ de la requête spécifique ; - pour l'exécution de la pluralité de requêtes d'interrogation spécifiques, on obtient, pour chaque requête spécifique, des identifiants des résultats de ladite requête, on synthétise lesdits résultats de manière à obtenir une liste d'identifiants des résultats de la requête d'interrogation de l'utilisateur, et on télécharge les données correspondant auxdits identifiants de ladite liste. L'invention sera mieux comprise à la lecture de la description non limitative qui suit, rédigée au regard des dessins annexés, dans lesquels : la figure 1 illustre les différentes phases du 20 procédé selon l'invention ; la figure 2 illustre un système pour la mise en œuvre du procédé selon l'invention, et détaille les différentes phases de ce procédé ; la figure 3 illustre plus particulièrement la phase 25 de transformation d'une requête d'interrogation selon l'invention ; et la figure 4 illustre plus particulièrement la construction itérative des conteneurs structurés selon le procédé de l'invention. 30 Le procédé selon l'invention est un procédé d'interrogation simultanée d'une pluralité de bases de données structurées, par exemple une dizaine de telles bases. Ces bases de données structurées sont, en particulier, des bases de données de propriété industrielle. Il s'agit notamment de bases de données brevets d'invention ou de marques ou de dessins ou modèles. De telles bases de données de propriété industrielles sont fournies par des offices de propriété industrielle, en général. On citera, par exemple, la base de données brevets Esp@cenetTM fournie par l'Office Européen des Brevets. On citera, dans un autre exemple, la base de données brevets PatentScopeTM produite par l'Office Mondial de la Propriété Intellectuelle. Le procédé d'interrogation des bases de données structurées selon l'invention est mis en œuvre dans un réseau informatique. Un tel réseau est par exemple le réseau Internet, un réseau du type Intranet ou un réseau mixte Internet/Intranet. L'interrogation des bases de données structurées, telle qu'elle est proposée par les fournisseurs desdites bases, est effectuée uniquement au travers d'interfaces d'interrogation. C'est la raison pour laquelle les moteurs et/ou les méta-moteurs de recherche n'ont pas accès auxdites données. Les interfaces d'interrogation des bases de données structurées sont hétérogènes. Les formats des interfaces sont différents. Il en va de même, en général, des syntaxes d'interrogation et des codes utilisés. Ainsi que cela est illustré à la figure 1, le procédé selon l'invention comporte différentes phases. Dans une première phase, un utilisateur élabore une requête d'interrogation au travers d'une interface d'interrogation générique. Dans une seconde phase, la requête d'interrogation élaborée par l'utilisateur est validée. Dans une troisième phase, la requête d'interrogation élaborée par l'utilisateur, puis validée, est transformée en une pluralité de requêtes d'interrogation spécifiques des bases de données hétérogènes interrogées. Dans une quatrième phase, la pluralité de requêtes d'interrogation spécifiques, qui résultent de l'étape de transformation précitée, est exécutée en vue d'obtenir des résultats en réponse à la requête d'interrogation de l'utilisateur. Ainsi que cela est montré à la figure 2, pour la mise en oeuvre de l'invention, un utilisateur accède à un réseau informatique Intranet et/ou Internet 1 au moyen d'un navigateur 2. Il s'agit, par exemple, de l'un des navigateurs suivants : Mozilla FirefoxTM, OpéraTM, Internet ExplorerTM. L'utilisateur se connecte alors à un serveur 3 apte à exécuter une application, pour la mise en oeuvre du procédé selon l'invention dans le réseau informatique. L'utilisateur peut être authentifié. L'authentification permet notamment récupérer et d'utiliser les préférences comme la langue de l'utilisateur et/ou un environnement de travail personnalisé. La phase d'élaboration de la requête d'interrogation au travers d'une interface générique comprend des étapes de sélection 4 d'une requête existante et de modification de cette requête, ou de création complète d'une requête, puis de rédaction de son contenu au travers d'une interface de saisie. En effet, si des requêtes ont déjà été créées, l'utilisateur peut en choisir une parmi celles-ci et la modifier pour élaborer une nouvelle requête. Pour créer une nouvelle requête, l'utilisateur commence par choisir un des modèles de formulaires disponibles. Il s'agit de formulaires dit � par champs � pouvant contenir un ou plusieurs champs liés entre eux par des opérateurs booléens ou d'un formulaire contenant une zone de texte. L'interface de saisie de la requête propose à l'utilisateur de choisir les fournisseurs 5 qui seront interrogés lors de la phase d'exécution. Les dictionnaires de traductions et les dictionnaires de synonymes 6 correspondants sont proposés en fonction des capacités des fournisseurs 5 choisis. L'utilisateur peut restreindre le choix des langues. Les formulaires � par champs � dispensent de spécifier des noms de champ, contrairement à la zone de texte dans laquelle le nom des champs doit être spécifié. Le formulaire � par champs � est composé d'une série de champs qui peut être étendue dynamiquement. Les champs utilisables dans les formulaires représentent l'union des champs proposés par l'ensemble des fournisseurs accessibles par le système. Le système servant de support au procédé propose un nom unique par champ pour une langue donnée même si ce même champ peut être nommé de différentes façons suivant les fournisseurs et les langues disponibles sur les interfaces des fournisseurs. Pour chaque nom de champ, il existe un nom abrégé. Par exemple, le champ ayant dans l'interface française pour nom � titre en français � et dans l'interface anglaise � French title � a une référence unique abrégée � TTL FR � utilisable dans la zone de texte. Le procédé selon l'invention réalise la conversion entre les noms des champs fournis par l'interface et les noms des champs correspondants pour chaque fournisseur de données interrogé lors des étapes ultérieures de validation et de transformation. Pour chaque champ, l'utilisateur donne une ou plusieurs valeurs séparées par des opérateurs d'interrogation. Chaque champ est lié aux autres par des opérateurs booléens, et plusieurs champs peuvent être regroupés logiquement par des parenthèses. Le nombre de valeurs et d'opérateurs pour un champ n'est pas limité par l'interface. Au fur et à mesure de l'écriture de la requête, une première validation est faite au niveau du navigateur 2. A cet effet, les formats spécifiques à certains champs comme les dates ou les codes de classifications sont vérifiés. Le contenu de la requête est transmis au serveur 3 au fur et à mesure. Un ensemble d'aides interactives peut alors retourner des suggestions 7 à l'utilisateur, ces aides étant sélectivement activables par l'utilisateur, soit interactivement, soit au travers de ses préférences. Par exemple, si elle est sélectionnée, la préférence auto-complétion 8 génère des suggestions qui sont retournées par le serveur 3 à l'interface utilisateur qui les affiche pour être sélectionnables par l'utilisateur. Il peut s'agir, par exemple, de suggestions de codes de classification ou équivalents retournées par le serveur 3 en fonction des mots-clés entrés par l'utilisateur dans sa requête et en fonction des fournisseurs choisis par l'utilisateur, et/ou en fonction du début de code rentré par l'utilisateur. Ces codes avec leur description sont retournés au navigateur 2 pour être affichés comme suggestions. Dans un autre exemple, si les synonymes 9 sont sélectionnés, des termes équivalents sont retournés par le serveur 3 à l'interface qui les affiche pour aider l'utilisateur à étendre ou au contraire affiner sa requête. Ces synonymes sont dépendants des langues associées aux fournisseurs choisis par l'utilisateur. La validation syntaxique est réalisée interactivement par l'analyseur syntaxique, qui retourne les erreurs à l'interface. Le procédé selon l'invention prévoit que des procédures supplémentaires 10 de suggestion soient ajoutées au système de suggestion et activable selon les choix de l'utilisateur. D'un autre côté, en fonction des champs choisis par l'utilisateur, des icones, textes ou autres formes d'information sont utilisés par le procédé selon l'invention pour afficher sur l'interface utilisateur les fournisseurs qui proposent ces champs et qui devraient donc être interrogés. Les différentes suggestions citées ci-avant sont configurables au niveau des préférences utilisateur, et modifiables pour chaque édition de requêtes. Par exemple, le choix des dictionnaires 6 de synonymes à utiliser. Ces validations et suggestions sont asynchrones, de façon à ne pas gêner l'utilisateur dans sa frappe. Elles peuvent aussi être complètement désactivées. Par ailleurs, l'interface de saisie propose de sélectionner les types d'information qui seront retournés par les fournisseurs 5. Par exemple, les revendications dans le cas d'un brevet ou l'indication du produit dans le cas d'un dessin ou modèle. Pendant l'édition de la requête par l'utilisateur ou à sa demande, la requête est vérifiée au niveau de la syntaxe de l'interface unique puis, au niveau de la syntaxe et des limitations propres à chaque fournisseur, des suggestions et des messages d'erreurs étant éventuellement affichés sur l'interface. Il s'agit de la phase de validation 11 de la requête utilisateur selon le procédé selon l'invention. Cette validation peut se faire dynamiquement si l'option est activée par l'utilisateur, ou uniquement lorsque l'exécution de la requête est demandée par l'utilisateur. La validation comprend donc en premier lieu la vérification que l'expression donnée par l'utilisateur est correcte par rapport à la syntaxe de l'interface liée au procédé selon l'invention. La syntaxe de l'interface unique n'est pas décrite dans la présente description. Il s'agit d'une syntaxe classique pour un système d'interrogation. Cette phase de validation est activée à la demande de l'utilisateur lorsqu'il a terminé de composer sa requête ou dynamiquement s'il veut une vérification et des suggestions dynamiques. Cette phase comprend une vérification au niveau du navigateur 2, avec messages d'erreur et suggestions ; une vérification indépendante du fournisseur, au niveau du serveur, avec messages d'erreur et suggestions (validation syntaxique) ; et, pour chaque fournisseur, une validation de la traductibilité, avec messages d'erreur et suggestions, et une traduction en fonction de la langue, avec insertion des synonymes. Le procédé selon l'invention utilise une description des caractéristiques 12 de chaque fournisseur. Cette description est enregistrée sur le système et est accessible au procédé. Cette description comprend au moins le type d'interface : a) champ de texte, b) nombre fixe de champs avec opérateurs logiques inter-champs modifiables, c) nombre fixe de champs avec opérateurs logiques inter-champs fixés, d) nombre variable de champs avec opérateurs logiques inter-champs modifiables, e) nombre variable de champs avec opérateurs logiques inter- champs fixés ; les noms ou identifiants de chaque champ et leurs équivalents pour l'interface utilisateur liée au procédé (utilisé pour la transformation) ; les formats utilisables pour chaque champ les opérateurs 12 utilisables entre les champs ; les opérateurs utilisables dans et pour chaque champ ; les délimiteurs utilisables ; les langues utilisables ; les options disponibles ; les limitations en nombre de caractères pour chaque champ et pour l'ensemble du formulaire ; les limitations en nombre de mots-clés pour chaque champ et pour l'ensemble du formulaire ; et les limitations en nombre d'opérateurs pour chaque champ et pour l'ensemble du formulaire. Si la validation a été réalisée suite à la demande d'exécution de la requête, le procédé selon l'invention transfère ensuite les informations validées globalement au composant qui s'occupe de la transformation 13. Ces informations se représentent sous forme d'un arbre logique d'expression qui est enregistré en mémoire. Au niveau du navigateur 2, la validation correspond à une vérification des syntaxes utilisées pour les champs date, codes disponibles auprès des fournisseurs, par exemple les codes de classification, qui permet d'afficher les formats attendus dans les champs correspondants ; et à une vérification de la logique des délimiteurs de champs, comme l'ouverture ou la fermeture de parenthèses, de guillemets, lorsque l'utilisateur demande l'exécution de la requête. Au niveau du serveur 3, et pour la validation, la requête est analysée par le composant de traitement qui comprend un analyseur syntaxique et un analyseur grammatical. L'analyseur syntaxique vérifie le contenu des champs qui ont des contraintes syntaxiques. Par exemple, le contenu d'un champ de références de documents est validé s'il est conforme à au moins une des syntaxes supportées par un des fournisseurs. 13 Pour chaque fournisseur, une procédure de validation pour les champs ayant des contraintes syntaxiques est déclarée dans les caractéristiques 12 du fournisseur et est appelé par le composant de traitement qui les utilise au travers de l'analyseur syntaxique. L'analyseur grammatical vérifie que l'expression est valide du point de vue grammatical et retourne si nécessaire des suggestions, comme les ouvertures ou fermetures de parenthèses, la position des opérateurs, ou les noms de champs. Ensuite, pour chaque champ, le composant de traitement fait appel au composant de suggestion qui a pour charge d'appeler les procédures de suggestions disponibles pour chacun de ces champs. Des exemples de ces suggestions sont : l'auto-complétion des mots en fonction des dictionnaires disponibles et choisis par l'utilisateur ; l'auto-complétion de codes, notamment ceux qui ont une structure hiérarchique ; la proposition de synonymes en fonctions des dictionnaires de synonymes disponibles et choisis par l'utilisateur ; et des suggestions de traduction de termes propres aux langues correspondantes à chaque fournisseur sélectionné. Pour la mise oeuvre de la phase de transformation selon l'invention, l'arbre d'expression de la requête est développé puis, en fonction des possibilités de chaque fournisseur, un traitement est réalisé. L'arbre est ensuite reconstruit pour créer des formes dont le contenu est directement traduit en un ensemble de formulaires de requêtes, qui sont des conteneurs structurés contenant des champs de données, des opérateurs et des délimiteurs. Chaque formulaire correspond à un ensemble d'informations ou requêtes fournisseurs, attendues par les interfaces spécifiques de chaque fournisseur. 14 La première étape de la transformation consiste à construire l'arbre de l'expression, et à effectuer un développement de cet arbre, qui a pour effet de faire remonter les opérateurs � OU � (� OR �) et de faire descendre les opérateurs � NON � (� NOT �), puis les opérateurs � ET � (� AND �). Par exemple : A ET (B OU C) est développé en (A ET B) OU (A ET C) A ET (B NON C) est développé en (A ET B) NON (A ET C) A NON (B OR C) (A NOT B) AND (A NOT C) Par la suite, le procédé selon l'invention utilise, pour chaque fournisseur, la description des caractéristiques de son interface ainsi que les procédés (ou règles si l'implémentation utilise un moteur de règles pour la transformation) permettant les traitements suivants : traitement des champs ; utilisation des champs de substitution ; optimisations complémentaires ; traitement des opérateurs inexistants ; recherche des restrictions (ex. : utilisation de codes de classification spécifiques à un fournisseur) qui imposent que les réponses ne peuvent être fournies que par un nombre restreint de fournisseurs, les branches liées à ce terme ou à cet identifiant réducteur n'étant pas prises en compte pour les autres fournisseurs ; découpage de l'arbre de requêtes fournisseurs en une liste de requêtes fournisseurs utilisables ; optimisation (statique) des requêtes par distribution des réducteurs (termes liés par des opérateurs ET) En fin de processus, une liste de requêtes par fournisseur est obtenue, dont les résultats sont réunis en une seule liste de résultats. 15 Pour le traitement des champs, on effectue une validation de contenu, une traduction du contenu, et une identification du contenu. Pour la validation du contenu, on détermine si chaque fournisseur peut avoir des formats particuliers pour certains champs, comme le champ � date �, qui nécessite ou pas une traduction. Pour sa traduction, le contenu est traduit du format originel au format attendu par le fournisseur par les fonctions spécifiques à chaque champ stocké dans la base de caractéristiques des fournisseurs. Dans un exemple, pour l'identification du contenu, le champ � numéro de publication � peut contenir un préfixe qui est le code pays ou le type de brevet désigné (ex : USR). Si le contenu du champ ne correspond pas à un contenu valide pour le fournisseur, il y a une recherche pour valider que le contenu du champ est valide pour au moins un des fournisseurs (étape de validation) utilisables par le procédé selon l'invention. Il est dans ce cas identifié comme appartenant aux fournisseurs correspondants et ne sera utilisé que pour les fournisseurs en question. Lorsque l'utilisateur interroge les fournisseurs sur des champs non disponibles auprès d'un fournisseur, le procédé selon l'invention les remplace, lorsque cela est possible et lorsque cela est spécifié dans les préférences de l'utilisateur, par d'autres champs appelés � champs de substitution �. Ces champs sont modifiables et évoluent en même temps que les capacités des fournisseurs. Par exemple, si le champ � full text � (� texte complet �) n'existe pas auprès d'un fournisseur, les champs d'interrogation � titre �, � titre ou 16 résumé �, � description � vont être utilisés à la place du champ � full text �. Il existe deux types de champs de substitution. Il s'agit d'une part, de ceux qui réduisent le nombre de réponses. C'est le cas, par exemple, des champs � titre � ou � description �, qui sont utilisés à la place d'un champ � full text �, car ils produisent un nombre de réponses à priori inférieur à celui que fournirait le champ � full text �. Il s'agit, d'autre part, de ceux qui augmentent le nombre de réponses. C'est le cas, par exemple, des champs � numéro de publication � et � numéro de demande � lorsqu'ils sont utilisés pour remplacer le code de classification US, utilisés avec un terme réducteur de réponses en l'occurrence � US �. L'utilisateur est informé que les réponses sont optimisées par rapport aux capacités du fournisseur. Dans certains cas, il peut être impossible de traduire ou de substituer un champ ou son contenu, il est alors abandonné pour le fournisseur en question et l'erreur est enregistrée pour être délivrée à l'utilisateur. Tous les fournisseurs ne proposent pas les mêmes opérateurs. Par exemple l'opérateur de complétion � caractère de remplacement � placé à la fin d'un mot ou d'une valeur n'est pas toujours disponible. Pour limiter la dégradation des résultats d'une requête, le procédé prévoit que, lorsque l'arbre comprend des opérateurs non reconnus par un fournisseur, un traitement particulier de l'arbre, déclaré dans les caractéristiques du fournisseur, soit appelé pour compenser ces manques. Les fournisseurs faisant évoluer régulièrement leurs interfaces d'interrogation, le procédé prévoit que les procédures de compensation soient mises à jour régulièrement avec les caractéristiques des fournisseurs. Des exemples de compensations utilisées sont les suivants : � PROCHE � (� NEAR �) est remplacé par un � ET � � NON � dans un champ est remplacé par un � NON � et un nouveau formulaire. Par exemple, FORM [X/(A NON B)] est remplacé par FORM [X/A] NON FORM [X/B] . Dans le cas où il serait impossible de compenser un opérateur, la branche de l'arbre sous cet opérateur serait supprimée, et l'utilisateur est informé par un message. Pour la construction itérative des formulaires, l'arbre de requêtes est complètement décomposé pour chaque fournisseur. Cette décomposition est présentée à la figure 3. Elle génère un arbre qui comprend un opérateur OU avec des ensembles de branches regroupées par des opérateurs ET. Chaque opérateur ET est l'équivalent d'un � méga � formulaire. Il n'est pas tenu compte des limitations imposées par le fournisseur. Un arbre est composé des éléments suivants : opérateurs et valeurs. Les opérateurs utilisés sont au minimum: OU, ET, NON, CHAMP, FORM. L'opérateur CHAMP comprend une expression et une valeur qui désigne le champ. Pour chaque fournisseur, la reconstruction de l'arbre se passe en deux étapes : une première étape de création itérative des formulaires et une seconde étape d'optimisation des formulaires. L'algorithme utilisé pour créer les formulaires à 30 partir de chaque méga formulaire est décrit par le diagramme à la figure 4. Cet algorithme tient compte de la possibilité qu'ont les fournisseurs de mettre des limitations : sur le nombre de caractères pour chaque champ et pour l'ensemble du formulaire, sur le nombre de mots-clés pour chaque champ et pour l'ensemble du formulaire, et sur le nombre d'opérateurs pour chaque champ et pour l'ensemble du formulaire. A chaque limitation rencontrée, un nouveau formulaire est créé. Il est rattaché à l'arbre par l'opérateur ET à la place du formulaire ayant atteint la limitation. Ce formulaire et celui créé étant les fils du ET. Ceci permet l'exécution complète de la requête voulue par l'utilisateur. Une phase d'optimisation est ensuite exécutée pour compléter les formulaires, dont l'algorithme basique d'optimisation consiste à compléter chaque champ d'un formulaire avec des valeurs du méga formulaire pour les champs qui ne sont pas déjà présents dans le formulaire, jusqu'à concurrence des limitations des champs et des formulaires. Des algorithmes plus pertinents peuvent être utilisés, comme l'utilisation de longueur de date ou de rareté d'un terme. L'optimisation décrite ci-dessous permet de limiter le nombre de réponses par requête. Le procédé 25 d'optimisation par défaut est le suivant : pour deux formulaires FORM B et FORM C, si un champ du formulaire FORM B a un nombre de valeurs inférieur au nombre de valeurs du même champ de l'autre formulaire FORM C, et que toutes les valeurs de ces champs sont 30 reliées entre elles par des opérateurs ET, ce qui correspond à l'essentiel des cas, les valeurs du champ C sont ajoutées aux valeurs du champ B jusqu'à épuisement des valeurs ou jusqu'aux limites autorisées du formulaire FORM B (exemple nombre de caractères, nombre de valeurs). Le résultat est une optimisation de la requête par augmentation du nombre de termes par champ ce qui diminue le nombre de réponses potentielles. Autrement dit, le nombre de réponses est considérablement réduit grâce aux transformations précitées. Les différents choix de combinaisons ces valeurs de � réduction forcée � établissent une liste de formulaires équivalentes appelé liste de formulaires de substitution. L'invention exploite les listes de formulaires de substitution lorsque le nombre de réponses à un formulaire est supérieur à un seuil fixé dans les préférences du système ou dans les préférences de l'utilisateur ou aux capacités du fournisseur. Cette exploitation est décrite dans la partie exécution et consiste à utiliser les autres formulaires pour obtenir une requête avec un nombre de réponses inférieur au seuil fixé ou pour trouver le nombre minimum de réponses. D'autres procédures d'optimisations dynamiques demandées par la procédure d'exécution peuvent être utilisées comme par exemple la décomposition d'une date dans un formulaire qui donne trop de réponses pour le fournisseur qui ne voudra donc pas renvoyer toutes les réponses. En effet, en fonction des fournisseurs, on peut par exemple remplacer un formulaire qui contient la date 2004 par une série de formulaires avec des dates plus précises comme 2004/01, puis 2004/02, jusqu'à 2004/12. Contrairement aux listes de formulaires de substitution, ces formulaires générés sont substitués dans l'arbre de requêtes au formulaire d'origine et liés entre eux par des opérateurs ET. 20 L'arbre est considéré comme optimisé lorsque l'on obtient un nombre minimum de formulaires générés, pour un nombre minimum de réponses. Pour la mise en œuvre de l'étape d'exécution, les formulaires de requêtes fournisseurs sont exécutés. Des tâches � requêtes fournisseurs � sont créées, ainsi que des tâches de traitement de données (indexation, analyse, etc). Ces différentes tâches sont exécutées en parallèle, de manière asynchrone, éventuellement sur plusieurs serveurs. L'utilisateur peut consulter, arrêter, relancer, mettre en différé ou interrompre définitivement l'exécution de ces tâches. Si une requête fournit trop de réponses et que la transformation a indiqué qu'il existe des alternatives à la requête en question, un service de transformation est appelé pour donner les requêtes équivalentes jusqu'à épuisement des requêtes alternatives, ou jusqu'à ce que l'exécution d'une requête satisfasse les conditions d'acceptabilité. L'étape de synthèse des résultats comprend des étapes consistant à, - récupérer tous les identifiants (ou références) d'information, - évaluer leurs correspondances par rapport à chaque fournisseur (syntaxes différentes pour référencer le même document ou la même information) et - réaliser les opérations logiques liées à l'arbre de la requête utilisateur pour éliminer les doublons et supprimer les indésirables (ex: liés à l'opérateur NON) pour construire des listes de références par fournisseur. Une fois que les listes des références ont été traitées, étape de récupération des données demandées par l'utilisateur, et stockage de ces données pour être ensuite présentées à l'utilisateur. 21 Pendant la phase d'exécution, les formulaires sont soumis aux fournisseurs, les résultats téléchargés et analysés. Cette phase est à la charge d'un contrôleur d'exécution 14 qui fait appel à un système de traitement tâches, par exemple le système de traitement de tâches 15 par lots Job SchedulerTM. On suppose que ce système 15 possède les fonctionnalités classiques suivantes : il permet de définir des groupes de tâches dont l'utilisateur ou le procédé peut surveiller la progression, et qu'il peut interrompre, suspendre, et relancer ; l'ensemble des tâches d'un groupe de tâches est modifiable. On peut ajouter des tâches à un job pendant 15 l'exécution ; plusieurs tâches peuvent être exécutées en parallèle ; la décision d'exécuter une tâche peut dépendre du fait que d'autres tâches ont été exécutées ; 20 il rend disponible les informations de progression des jobs et des tâches. La phase d'exécution est donc mise en oeuvre au moyen du contrôleur d'exécution 14. Ce contrôleur d'exécution contrôle le système de traitement par lots. En 25 particulier, il crée les groupes de tâches, ajoute des tâches auxdits groupes. Il gère les arbres d'expressions logiques. En particulier, il ajoute, supprime ou remplace des branches desdits arbres. Il optimise les exécutions, réalise une synthèse des résultats et effectue le 30 téléchargement 16 des données associées. Cette phase d'exécution comporte trois étapes principales. Il s'agit d'une première étape de détermination des identifiants pour chaque formulaire ; d'une seconde étape de synthèse des identifiants de résultats ; et d'une troisième étape de téléchargement des données associées. Pour la détermination des identifiants, les requêtes permettant d'obtenir les identifiants des résultats sont envoyées aux fournisseurs. Il s'agit par exemple d'un numéro de publication dans le cas d'un brevet, quitte à avoir des redondances (causées par la décomposition) ou des résultats finalement inutiles (par exemple résultant d'opérateurs NON FORM). Pour cela, lorsque le transformateur fournit au contrôleur d'exécution l'arbre d'expression contenant un ensemble de formulaires, le contrôleur d'exécution crée un groupe de tâches et ajoute un ensemble de tâches dites d'interrogation à ce groupe de tâches, en pratique, une tâche par formulaire. Les tâches d'interrogation sont définies comme étant formées d'une suite logique d'opérations. Ces opérations sont les suivantes : - une opération d'interrogation d'un fournisseur via le service d'accès aux fournisseurs ; - une analyse et traitement des résultats en sortie du service ; - un stockage des informations analysées Lorsque le système de traitement des tâches exécute une tâche d'interrogation, le formulaire est envoyé au service d'accès aux fournisseurs 17 qui a en charge la gestion des échanges avec les fournisseurs. La communication proprement dite du service d'accès aux fournisseurs avec chaque fournisseur concerne par exemple la gestion du protocole, les différents échanges qu'il peut y avoir notamment dans les cas de redirection ou de gestion de cookies. Lors de l'exécution d'une tâche, lorsque l'interrogation d'un fournisseur est terminée, la tâche analyse et traite les données renvoyées par le fournisseur, les stocke et informe le contrôleur d'exécution pour qu'il décide de la suite des opérations. Si la requête au fournisseur a échoué, le contrôleur d'exécution décide de reformuler la requête, en remplaçant cette tâche par une ou plusieurs requêtes alternatives, s'il reste des formulaires de substitution disponibles auprès du transformateur ou contenus dans l'arbre de formulaires fourni par le transformateur. Par exemple, si une requête donne trop de réponses et dépasse les limites du fournisseur, elle peut être remplacée par un ensemble de formulaires de requêtes plus restrictives qui, réunies, seront équivalentes à la requête initiale. Le contrôleur d'exécution ajoute alors au job les tâches correspondantes à ces nouvelles requêtes. Si la requête au fournisseur a réussi, le contrôleur d'exécution stocke dans la base de données la liste des identifiants des résultats associés au formulaire. Le contrôleur d'exécution peut aussi optimiser l'ensemble des tâches à effectuer. Par exemple, si, dans l'arbre de requêtes, deux formulaires sont liés par un opérateur ET, et qu'un formulaire ne donne pas de résultat, la tâche correspondante à l'autre formulaire lié par le ET sera supprimée du lot, sans avoir été lancée. Il est effectivement dans ce cas inutile d'effectuer les requêtes de l'autre branche, le résultat de l'opération logique ET ne renverra logiquement, de toute façon, aucun résultat. Lorsque toutes les tâches d'interrogation ont été effectuées, le contrôleur d'exécution effectue une synthèse des résultats, qui donne la liste des identifiants des résultats de la requête initiale de l'utilisateur. Elle effectue pour cela un parcours en profondeur de l'arbre d'expression et détermine alors la liste des identifiants des résultats correspondants à chaque nœud selon une opération dépendante du type de nœud. Si le nœud est un formulaire, sa liste de résultats a été fournie par l'analyse du résultat de la tâche d'interrogation correspondante. Si le nœud est un opérateur ET, sa liste de résultats est l'intersection des listes de résultats de ses fils. Si le nœud est un opérateur OU, sa liste de résultats est l'union des listes de résultats de ses fils. Si le nœud est un opérateur NON, sa liste de résultats est la différence des listes de résultats de ses fils. L'arbre et ses données sont stockées, la liste complète des identifiants des résultats de la requête initiale est alors la liste associée à la racine de l'arbre. Le procédé ne se limite pas à la détermination des identifiants ou références des résultats. Il permet en outre le téléchargement d'un certain nombre d'informations demandées par l'utilisateur sur ces résultats. A cet effet, le contrôleur appelle le composant de transformation en lui communiquant la liste des résultats. Il obtient en retour la liste (arbre avec uniquement des OU) des formulaires correspondants. Pour chaque fournisseur proposant l'accès direct aux informations à partir d'un ou plusieurs identifiants, l'algorithme de création de ces formulaires est simplement une boucle qui ajoute les identifiants des résultats jusqu'à concurrence de ce qu'autorise chaque fournisseur pour ce type d'interrogation. Cette dernière étape de génération de formulaires permet de minimiser le nombre de nouvelles requêtes à envoyer aux fournisseurs 25 et donc d'optimiser le temps de récupération des informations. Pour chacun de ces formulaires, le contrôleur d'exécution crée une tâche dite de récupération pour le téléchargement des données demandées par l'utilisateur et l'ajoute au groupe de tâches. Lorsque le système de traitement par lots exécute une tâche de récupération, le formulaire correspondant est envoyé au service d'accès aux fournisseurs qui a en charge la gestion des échanges avec les fournisseurs. La tâche de récupération est caractérisée par le fait qu'elle contient la description des données à télécharger, description qui sera utilisée par le service d'accès aux fournisseurs qui connait le procédé pour récupérer lesdites données. Par le même mécanisme décrit pour les tâches d'interrogation, le système de traitement par lots procède alors au téléchargement des données. On notera que les données sont téléchargées dans un dernier temps de la mise en œuvre du procédé selon l'invention, soit après les étapes de récupération et de traitement des identifiants des données. Lorsque l'une de ces tâches reçoit le résultat de la récupération, elle analyse les résultats et les données téléchargées, puis elle informe le contrôleur d'exécution. Le contrôleur stocke les données téléchargées dans la base de données, puis télécharge les informations auprès d'autres fournisseurs si le transformateur a indiqué qu'il y a des alternatives de fournisseurs et si les données téléchargées ne contiennent pas les informations requises. Il crée alors d'autres tâches de téléchargement et les ajoute au groupe de tâches. Lorsque le téléchargement des données associées est terminé, le groupe de tâches est exécuté. La phase d'exécution est terminée. On notera que la mise en œuvre du procédé selon l'invention est rapide, car la récupération des identifiants ne nécessite pas un transfert important de données, contrairement au téléchargement des données elles-mêmes. REVENDICATIONS1. Procédé d'interrogation d'une pluralité de bases de données structurées interrogeables, dans un réseau informatique, au travers d'interfaces d'interrogation hétérogènes, caractérisé en ce qu'il comporte les phases suivantes selon lesquelles : un utilisateur élabore une requête d'interrogation au travers d'une interface d'interrogation générique ; la requête d'interrogation est transformée en une pluralité de requêtes d'interrogation spécifiques des bases de données hétérogènes interrogées ; et la pluralité de requêtes d'interrogation spécifiques est exécutée en vue d'obtenir des résultats en réponse à 15 la requête d'interrogation de l'utilisateur, et en ce que la phase de transformation de la requête d'interrogation comprend une étape selon laquelle un arbre de l'expression de la requête est construit puis développé de manière à obtenir un arbre développé, qui 20 est traduit, pour former des arbres spécifiques de chacune des bases de données hétérogènes interrogées. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre une phase de validation de la 25 requête élaborée par l'utilisateur. 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que, pour l'élaboration de la requête d'interrogation, l'utilisateur utilise un formulaire 30 comportant un ou plusieurs champs liés entre eux par des opérateurs booléens et en ce que des données saisies dans ledit formulaire sont vérifiées dynamiquement avec un serveur, lors de l'élaboration de la requête. 4. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que, pour l'élaboration de la requête d'interrogation, l'utilisateur utilise une zone de texte générique. 5. Procédé selon l'une des revendications 2 à 4, caractérisé en ce que la validation de la requête élaborée par l'utilisateur est assurée par un composant de traitement, qui comprend un analyseur syntaxique et un analyseur grammatical. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que, pour former une requête spécifique d'une base de données, on crée des formulaires de manière itérative de sorte que, à chaque limitation rencontrée pour l'interrogation de ladite base de données, un nouveau formulaire est créé puis rattaché à l'arbre développé traduit. 7. Procédé selon la revendication 6, caractérisé en ce que les formulaires créés sont optimisés en augmentant le nombre de termes de recherche par champ de la requête spécifique. 8. Procédé selon l'une des revendications précédentes, caractérisé en ce que, pour l'exécution de la pluralité de requêtes d'interrogation spécifiques, on obtient, pour chaque requête spécifique, des identifiants des résultats de ladite requête, on synthétise lesdits résultats de manière à obtenir une liste d'identifiants des résultats de la requête d'interrogation de l'utilisateur, et on télécharge les données correspondant auxdits identifiants de ladite liste.