Travail dirigé de Martin Sévigny, ©1996 Section précédente | Section suivante | Page d'accueil |

10. Discussion des résultats

L'évaluation par des usagers, présentée dans la partie précédente, nous a permis de réfléchir à des améliorations que nous pourrions apporter à ERIS. Bien entendu, la réalisation de ce projet de recherche nous a également permis de mener une réflexion générale sur l'interrogation de documents structurés et sur les outils nécessaires pour y arriver.

Dans les pages qui suivent, nous présentons les éléments de cette réflexion, qui pourrait en quelque sorte guider les futurs concepteurs de bases de documents structurés et d'outils de recherche appropriés.

10.1 La notion de structure en recherche

Les commentaires émis par les évaluateurs nous ont amené à pousser plus loin (et à modifier quelque peu) la réflexion que nous avions menée en début de projet (étape 3 de la méthodologie) sur l'utilisation de la structure en recherche.

Toute information stockée dans une base de données acquière (en plus de celle qu'elle possède déjà) une certaine structure. Là où les documents structurés se distinguent, c'est dans l'importance que prend cette structure et dans sa complexité potentielle. Dans la plupart des systèmes de gestion de bases de données textuelles, les usagers interrogent les documents à l’aide de certains champs ou index, pour lesquels ils spécifient des critères de recherche textuels, c’est-à-dire relatifs au contenu des champs. De plus, il peuvent habituellement relier les critères d’un même champ ou de différents champs à l’aide d’opérateurs, booléens la plupart du temps. Par conséquent, tout ce que l’usager a besoin de connaître, ce sont les champs ou index disponibles et leur signification. Bien entendu, plus il en connaît sur la méta-information (dictionnaire de données), plus ses recherche pourront être fructueuses.

Dans le cas des documents structurés, l’usager doit aussi connaître les champs (éléments de structure logique) et leur signification, mais en plus, il risque d’y avoir un grand nombre de types d’éléments, et il existe des relations entre ces éléments. À l'opposé, dans une base de données de type fichier plat, il existe une seule relation: les champs se situent sous les documents, d’un point de vue hiérarchique. On pourrait ajouter que les documents se retrouvent sous la base, mais on ne peut aller plus loin.

Selon nous, même si les usagers connaissent les implications de l’interrogation de documents structurés, c’est-à-dire même s'ils savent qu’ils peuvent non seulement interroger le contenu mais également la structure des documents, il demeure nécessaire d'avoir recours à des outils spécialisés.

Les réactions des évaluateurs nous ont fait constater qu'à l'heure actuelle, les usagers ne connaissent pas vraiment les implications de l'interrogation de documents structurés. Il semble que les documents structurés que l’on peut interroger en exploitant leur structure sont trop rares pour que les usagers potentiels soient familiers avec ces concepts. Il est donc certain que la plupart des usagers ne seront pas habitués à utiliser de tels outils, même spécialisés. Il est même probable que les notions de relations entre les éléments portent à confusion chez certains.

Si un jour nous voulons en arriver à de meilleurs environnements d’interrogation qui répondront encore mieux aux besoins des usagers et si, pour y arriver, nous utilisons des documents structurés, il ne faudra pas oublier que dans une première phase, les usagers seront des novices dans l’exploitation de la structure et même dans la compréhension de cette notion. Ceci demande, encore une fois, non seulement des outils adaptés aux documents structurés, mais en plus adaptés à des novices en la matière. Il y aura toute une terminologie à construire, des conventions à établir, etc.

Nous avons observé chez les évaluateurs une certaine confusion lorsqu’ils sont confrontés à des éléments de structure des documents. Malgré les explications théoriques, la mise en pratique n’était pas facile. Bien entendu, il s’agissait de leur premier contact avec l’interrogation de documents structurés, mais ils avaient tout de même une certaine familiarité avec les documents structurés eux-mêmes et avec l’interrogation de bases de données en général.

Concevoir une interface qui va permettre de réduire ou même supprimer cette confusion constitue un défi important, en partie seulement relevé dans le cadre de ce projet. Toutefois, un peu plus loin nous présenterons certaines pistes à explorer pour faire un autre bout de chemin vers cet objectif ambitieux.

10.2 Portes d’entrée vers l’information

Dans ERIS, la fenêtre de présentation des résultats et le guide détaillé de la structure ont un caractère commun: chacun constitue un sous-ensemble de la base de documents. La fenêtre des résultats présente un sous-ensemble dans le but de faciliter la navigation dans les résultats de recherche. Le guide détaillé de la structure, de son côté, présente un sous-ensemble de la base afin d’aider l’usager à mieux connaître la structure.

L’utilisation de sous-ensembles, que nous appellerons portes d’entrée car ils permettent de voir une partie des documents sous un certain angle, constitue une idée d’interface à exploiter davantage. L’usager pourrait tirer profit de ces portes d’entrée, car elles simplifient la compréhension de la base de documents et lui permettent de se construire des petites bases personnelles, à partir de certaines parties de la ou des grandes bases.

Nous avons déjà expliqué que la fenêtre de présentation des résultats doit utiliser les mêmes éléments d’interface que le module de consultation des documents, et c’est pourquoi il semblait naturel de les présenter en mode de navigation hypertextuelle. En y ajoutant des éléments tels que des signets ou l’historique des éléments visités, l’usager pourra facilement se construire son petit univers personnel dans la base.

Le guide détaillé de la structure, présenté en mode graphique, possède un potentiel très peu exploité dans le cadre de ce projet. En effet, sa présentation a séduit les usagers et l’approche en arbre inversé semble être efficace afin de présenter des éléments hiérarchiques.

Ce module pourrait devenir l’embryon d’une interface où les éléments graphiques sont plus présents. Par exemple, les résultats de recherche pourraient également être présentés de cette façon. De plus, une telle représentation pourrait servir de navigateur lors de la consultation des documents. Enfin, elle pourrait même servir de base à une formulation graphique des requêtes, ce qui fera l’objet d’une piste de recherche présentée un peu plus loin. Une chose est sûre, cet élément d’interface pourrait être exploré plus à fond.

10.3 Le rôle des différents intervenants

Pour réaliser ce projet de recherche, nous avons effectué presque toutes les étapes qui permettent de publier de l’information sous forme électronique, et qui permettent aux usagers d’effectuer des recherches dans cette information. Nous allons maintenant voir quelles sont les particularités de cette démarche dans le contexte d’une base de documents structurés. Pour y arriver, nous allons séparer la démarche en quatre parties, représentées par les rôles joués par l’auteur, l’éditeur, le concepteur du logiciel et l’usager.

10.3.1 Auteur

L’auteur est celui qui crée les documents, l’information. Son rôle est primordial et en principe, cette information devrait être indépendante du processus d’édition qui suit. Toutefois, cette situation idéale n’est pas toujours possible ou réalisée. Pour y arriver, l’auteur devrait fournir son information sous la forme d’un ou de plusieurs documents structurés, soit un document électronique contenant de l’information sur la structure logique.

Il est intéressant de noter que l’être humain conçoit des documents (du moins ceux destinés à diffuser de l’information) en fonction d’une structure logique qu’il possède très bien. Nous sommes habitués à travailler avec des plans, des chapitres, des sections, etc. Créer un document structuré ne devrait pas causer de problèmes.

Toutefois, la disponibilité grandissante et la facilité d’utilisation des logiciels de traitement de textes et de publication assistée par ordinateur viennent modifier cette approche. En effet, même si l’auteur pense en fonction d’une structure logique, il va rédiger son document et les balises qui l’accompagnent en fonction de l’apparence du document. Ainsi, il va insérer des codes de formatage plutôt que des éléments de structure logique. Il va donc à l’encontre de sa façon de penser.

Demander à un auteur de fournir des documents structurés exige donc un certain effort, car il n’y sera pas habitué. De plus, cela demande habituellement une certaine rigueur, puisqu’on doit respecter une grammaire (DTD) bien définie. Cet effort peut sembler contraignant si on le compare à l’édition à l’aide d’un traitement de textes. Toutefois, il s’agit d’une structure moins complexe que d’entrer des informations dans une base de données par exemple, où les règles à suivre sont souvent plus strictes que pour les documents structurés. De plus, il s’agit d’un "retour au naturel", puisque l’être humain réfléchit de cette façon, avec une approche structurée.

Par conséquent, nous considérons que l’auteur devrait fournir ses documents dans un format structuré, en tentant d’inclure le plus d’information possible sur la structure logique. De plus en plus d'outils (éditeurs structurés) existent pour accomplir cette tâche et il n'est pas utopique de croire que plusieurs auteurs seraient prêts à les utiliser. Si l'auteur ne peut y arriver, l’éditeur devra le faire, ce qui risque de diminuer la qualité du processus puisqu’en général il n’est pas aussi bien placé que l’auteur pour déterminer la structure logique d’un texte.

10.3.2 Éditeur

Pour les fins de cette discussion, nous allons considérer l’éditeur comme celui qui prend la décision de publier les documents structurés fournis par l’auteur. Les éditeurs seront souvent ceux qui rassemblent l’information pour en faire des ensembles cohérents, font des choix parmi de nombreux documents pour sélectionner les meilleurs, etc. Cette définition ne diffère pas de celle donnée depuis longtemps aux éditeurs, mais leur rôle et leur façon de travailler pourraient être modifiés par la diffusion de bases de documents structurés.

Une fois que l’éditeur a arrêté son choix sur les documents structurés, il devra fournir un certain nombre d'informations au concepteur du logiciel, afin que ce dernier puisse les compiler et permettre ainsi la consultation et la recherche dans les documents. Nous allons explorer en détail ces informations, car c’est à ce niveau que la diffusion de documents structurés amène le plus de changements. Si l'éditeur distribue son information à l'aide de plusieurs logiciels différents, il devra adapter ces informations pour chaque logiciel.

Une des conclusions tirées à la suite de cette recherche concerne l’importance de présenter un maximum d’informations sur la base à l’usager, importance encore plus grande lorsqu’il s’agit d’une base de documents structurés. C'est ce que nous avons appelée la "méta-information sur la base de documents" (ou plus simplement "méta-information") à la page 47, cette méta-information étant constituée de ce qu'on retrouve habituellement dans le dictionnaire de données d'une base de données et de certaines autres informations. L’éditeur devra être responsable de consigner cette méta-information et de la fournir au concepteur du logiciel.

La méta-information sur une base de documents devrait inclure ces parties:

Définition formelle des documents

Les documents structurés doivent respecter une certaine définition formelle, ou grammaire. Dans le contexte SGML, il s’agit de la DTD. L’éditeur est responsable de fournir cette définition, puisqu’elle est absolument nécessaire au logiciel. À noter qu'il doit aussi la fournir à l'auteur, lorsque ce dernier doit la respecter.

Description de la base

Un ensemble de documents structurés doit avoir son rôle, sa raison d’être. L’éditeur doit fournir ces informations afin qu’elles soient rendues disponibles par le logiciel. On pense notamment à l’objectif de la base, sa portée, sa fréquence de mise à jour, et toute autre information générale pertinente.

Description des identificateurs génériques et des noms d'attribut

Chaque identificateur générique ou nom d'attribut utilisé dans la base a une signification précise et un rôle important à jouer. L’éditeur doit fournir ces informations, qu’il puisera dans les commentaires de la DTD ou dans un guide l’accompagnant si on se situe dans un contexte SGML. Il est important de noter que seules les descriptions des identificateurs génériques et noms d'attributs utilisés dans la base doivent être présentes. Cela correspond à la notion de structure réalisée, telle que discutée à la page 48.

Règles et styles de présentation

La présentation des résultats obtenus en recherche d’information structurée diffère selon le type d’éléments retournés. L’éditeur doit donc fournir les informations nécessaires, soit les identificateurs génériques qui seront affichés en entier, ceux qui seront représentés par un descripteur. Dans ce cas, il doit aussi spécifier quel sera ce descripteur.

Un document électronique est plus agréable à consulter s’il utilise différents styles, soit un texte "riche". Afin de permettre cette présentation, l’éditeur devrait fournir une feuille de style, qui définit ainsi toutes les instructions de formatage nécessaires pour une présentation agréable des documents.

Règles d’indexation

Comme pour toute base de données, l’indexation peut prendre différentes formes en fonction des différents "champs". L’éditeur devrait fournir des renseignements sur les éléments à indexer et de quelle façon.

Bordereaux de saisie de requêtes

L’utilisation de bordereaux pour effectuer des requêtes peut s’avérer fort efficace dans bien des situations. D’autant plus si les bordereaux sont bien adaptés aux besoins de recherche des usagers, et en particulier les besoins les plus fréquents. Deux intervenants sont les mieux placés pour définir de tels bordereaux: les usagers eux-mêmes et l’éditeur. Ce dernier connaît bien l’information dans sa base, de même que sa structure, et devrait être en mesure de fournir des bordereaux utiles au concepteur du logiciel, et donc aux usagers.

Règles de fonctionnement

Si jamais certains éléments des documents doivent engendrer des actions particulières, l’éditeur doit fournir ces informations. Dans un contexte SGML, c’est le cas avec les liens hypertextuels, qui ne font pas partie de la norme, mais doivent être interprétés à partir de la présence de certains éléments.

10.3.3 Concepteur du logiciel

Le concepteur du logiciel d’interrogation de documents structurés doit permettre à des usagers de consulter et interroger des documents rédigés par un auteur et diffusés par un éditeur. Pour y arriver, il doit concevoir un environnement constitué d’un système de compilation des documents, d’un moteur de recherche et d’une interface.

Le système de compilation des documents doit permettre de traiter toute l’information fournie par l’auteur et l’éditeur, soit les documents et la méta-information sur la base de documents, pour les rendre compatibles avec l’interface. Cela inclut la représentation interne des données et l’indexation. Ce système doit être suffisamment souple pour permettre de traiter tout type de documents et de s’adapter aux prescriptions sur les styles de présentation, les règles de présentation des résultats et d’indexation, les bordereaux à définir, etc.

L’interface doit être adaptée à l’interrogation de documents structurés, et respecter en particulier les recommandations formulées dans ce rapport. Les critères habituels d’utilisabilité doivent également être respectés. Finalement, le moteur de recherche doit permettre toutes les opérations définies par un langage de recherche pour les documents structurés.

Les deux aspects les plus importants du rôle du concepteur du logiciel d’interrogation sont la qualité de l’interface et la souplesse de l’environnement. En effet, nous avons montré que la conception d’une interface-utilisateurs pour l’interrogation de documents structurés nécessitait beaucoup de soins. De plus, si le logiciel doit être utilisé avec de nombreuses bases de documents qui varient énormément dans leur structure, il devra être suffisamment souple afin d’éviter de le reprogrammer pour chaque base. Nous considérons que ces deux qualités ne sont pas faciles à atteindre.

10.3.4 Usager

Finalement, nous voulons souligner que l’usager a aussi un rôle à jouer dans la démarche. L’usager est d’abord responsable d’adapter son environnement de recherche à ses besoins généraux. Le logiciel devrait notamment permettre à l’usager de déterminer ses "préférences" et ce dernier doit en tirer profit. Ces préférences sont habituellement reliées au fonctionnement général de l’interface.

Ensuite, on devrait permettre à l’usager de définir ses propres feuilles de style pour la présentation des documents. Cela devrait se faire selon un mécanisme simple mais puissant. Le logiciel doit donc permettre cette fonction, ce qui est du ressort du concepteur au moment de construire son interface. L’usager devrait également pouvoir définir ses propres bordereaux de recherche. Ajoutés à ceux définis par l’éditeur, ceci lui permettra d’effectuer certains types de requêtes fréquentes avec une grande facilité.

L’usager sera aussi responsable de gérer ses stratégies de recherche, que ce soit l’historique des requêtes ou encore les noeuds visités en mode hypertextuel.

10.3.5 Vue d’ensemble

En situation réelle, les rôles des différents intervenants ne sont souvent pas définis aussi clairement que dans les sections précédentes. D’ailleurs, il faut bien noter que la classification utilisée ne fait pas référence à des individus ou des institutions, mais bien à des rôles. Les différents rôles pourraient, dans certaines situations, être tous tenus par la même personne, même s’il ne s’agit pas nécessairement de la solution la plus efficace.

D’ailleurs, plusieurs tâches d’éditeur pourraient être effectuées par l’auteur des documents, s’il connaît bien les enjeux et les conséquences de ses actions. De la même façon, le concepteur du logiciel pourrait prendre des décisions laissées habituellement à l’éditeur, même si en général cette méthode n’est pas à conseiller.

L’important est de retenir que la méta-information doit accompagner les documents, et que cette méta-information doit être complète. Dans ce cas, on augmente les probabilités que l’ensemble de la démarche soit un succès.

10.4 Le rôle du spécialiste de l’information

Le deuxième objectif de ce travail de recherche était de réfléchir au rôle que peut jouer le spécialiste de l’information dans la conception d’outils de recherche. Après un an de travail sur un projet de la sorte, certaines réflexions en sont effectivement issues. Pour bien comprendre ces réflexions, nous allons séparer la conception de l’interface et la réalisation du logiciel.

Afin de bien situer les enjeux de la conception d’une interface humains-ordinateurs, nous allons nous inspirer de Preece (1993) et mentionner les connaissances de base que doit posséder le concepteur d’une interface:

Si le concepteur arrive à bien connaître ces informations, il pourra utiliser ses connaissances (nécessaires) sur l’ergonomie et en particulier les interfaces pour réaliser la conception d’une interface qui respecte tous les critères d’utilisabilité. Par la suite, il faut réaliser le logiciel comme tel, c’est-à-dire coder l’interface et la coupler au "système" sous-jacent.

Il y a deux façons de parvenir à concevoir le logiciel (y compris l’interface) que nous allons considérer optimales, car elles devraient résulter en une excellente interface.

La première façon est de faire travailler en équipe un ou des spécialistes de chaque domaine. Ainsi, associer des gens qui connaissent bien les usagers, leurs besoins et les tâches qu’ils voudront accomplir, l’environnement où le système sera utilisé et les limites techniques. Il ne faut pas oublier d’ajouter les gens qui vont réaliser le logiciel, que nous appellerons les programmeurs. Cette approche sera optimale en autant que tous arrivent à travailler en symbiose, ce qui n’est pas facile et en constitue la faiblesse.

La deuxième approche consiste à trouver une seule personne qui soit spécialiste de tous les domaines mentionnés. En principe, elle devrait arriver à un résultat très intéressant avec un effort minimal. Toutefois, la grande faiblesse vient du fait que trouver une telle personne est une tâche très difficile et pour bien des domaines, il n’en existe probablement pas.

Les limites des deux approches nous amènent à trouver des solutions de compromis, et c’est à ce moment que le spécialiste de l’information peut jouer un rôle important. Par sa formation, il est déjà un spécialiste des trois premiers éléments mentionnés par Preece, soit les usagers, les besoins et tâches ainsi que l’environnement. De plus en plus, les spécialistes de l’information sont bien au courant des possibilités et limites offertes par l’informatique, soit le quatrième point.

Si certains spécialistes de l’information pouvaient aller chercher des connaissances approfondies dans le domaine des interfaces humains-ordinateurs, le seul autre domaine manquant serait la programmation. Mais même sans cette connaissance nous serions en présence d’une situation qui se rapproche du deuxième scénario optimal, puisqu’il y aurait seulement deux groupes d’intervenants, soit les spécialistes de l’information et les programmeurs.

Réduire de cette façon le nombre d’intervenants peut avoir des conséquences heureuses. En effet, les spécialistes de domaines différents ont souvent des méthodes de travail ainsi qu'un langage particuliers, ce qui rend les échanges interdisciplinaires plus difficiles. Dans le scénario de compromis que nous proposons, les échanges interdisciplinaires seraient limités à ceux entre les programmeurs et les spécialistes de l’information. Ces derniers possédant de plus en plus de bonnes connaissances informatiques, le dialogue devrait être plus facile et les échanges plus fructueux.

Ce travail de recherche a été réalisé par un étudiant en bibliothéconomie et sciences de l’information possédant des connaissances à la fois dans le domaine des interactions humains-ordinateurs et en programmation. De plus, le directeur de recherche était un informaticien de formation mais travaillant maintenant dans le domaine du repérage de l’information dans un département associé aux sciences de l’information et non à l’informatique. Il s’agit d’un cas particulier se rapprochant encore plus de la deuxième solution optimale, mais nous considérons que la collaboration avec des programmeurs pourrait aussi s’avérer très fructueuse.

10.5 Recommandations

Afin de mettre en relief le caractère concret de ce projet de recherche et de ses conclusions, nous voulons les résumer en présentant cinq recommandations pour la conception d’interfaces destinées à l’interrogation de documents structurés. Ces recommandations n’apportent rien de nouveau par rapport aux points de discussion précédents, mais en sont plutôt une synthèse.

    1. Ne jamais oublier que l’utilisation de la structure en recherche constitue une nouveauté pour la plupart des usagers.

Il faudrait donc s’assurer de guider les usagers, de leur offrir une interface qui leur présente toute l’information désirée, et qui peut composer avec leurs erreurs.

    2. Utiliser une méthode graphique pour présenter les informations sur la structure des documents.

Les documents peuvent être associés à un réseau, et souvent à une hiérarchie. Pour l’être humain, ces concepts s’expriment et s’expliquent de façon optimale en utilisant des représentations graphiques plutôt que des listes ou du texte.

    3. Permettre à l’usager de consulter la méta-information sur la base de documents.

En principe, cette recommandation devrait être suivie par tous les concepteurs de logiciels d’interrogation de bases de données. Toutefois, elle prend encore plus d’importance dans un contexte de documents structurés, où les informations sont très nombreuses et importantes. L’interface devrait entre autres permettre la recherche dans la méta-information.

    4. Utiliser différentes portes d’entrée vers les documents.

Ces portes d’entrée sont essentielles pour permettre à l’usager de se construire des visions personnelles des informations contenues dans les documents. Elles contribuent également à diminuer la complexité apparente des documents structurés.

    5. Permettre une représentation graphique des résultats et la formulation graphique des requêtes de recherche.

Même si ces éléments restent à concevoir, ils semblent promis à un avenir intéressant puisqu’ils reposent sur des concepts naturels pour l’être humain.

Si ces recommandations sont suivies, de même que les recommandations générales pour la conception d’interfaces, on devrait obtenir une interface qui présente un haut niveau d’utilisabilité.


Travail dirigé de Martin Sévigny, ©1996 Section précédente | Section suivante | Page d'accueil |